Re: dwr in a clustered environment: ClusterScriptSessionManager?

JoeWalker wrote:

To ensure proper synchronization you need to have single access to both
maps. By which I mean while someone is updating one map, then the system
should ensure that the other map with also remains un-updated.

It might be that to provide this you need to have your SessionHolder provide
synchronization rather than the maps - although the whole subject of remote
sync.ing seems like a non-starter to me.

As far as init goes, you can register any object in the Container, so your
HAManager could be just another component. I am to keep the implementation
instructions as simple and future proof as possible, and I think that
requiring a new servlet is probably more than is needed. But by all means do
whatever you want and I'll refactor to make it fit.

Joe.


On 11/9/06, marc <inudor@hotmail.com> wrote:
>
>
> Hi,
>
> our first design defines a SessionHolder object that packages the two
> maps,
> session and pageSession.
> This information is mantained for every node. When a node is up, it will
> ask
> for it to the cluster coordinator
> node, and new sessions created in each node will be notified through the
> jgroups bus.
>
> To make this possible, we define ClusteredScriptSession and
> ClusteredScriptSessionManager and its default
> implementations, that must be Serializable objects to travel through the
> bus. This is why these default
> implementations don't use the sessionLock Object (it's not Serializable).
> Instead, our Maps are
> EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap, from concurrent 1.3.4
> (the same as
> in java.util.concurrent for J2SE5). This package is one of the two
> dependencies of our project apart from
> dwr. Those are JGroups, and its dependency Concurrent (this is why we use
> it, because we already have it).
>
> The integration with dwr has been thinked as an extension of DwrServlet,
> not
> using a init-param, because
> we need to initialize our HAManager and its channel, so we do it in the
> servlet's init method (after invoking
> its parent, DwrSerlvet.init()), and overwriting then the
> ScriptSessionManagerParameter.
>
> This is our first idea to keep the Sessions info synchronised between
> nodes.
> Now, we are designing how to
> broadcast the information about scripts added and consumed to
> ScriptSessions, which seems that will result in
> broadcasting the script info and the scriptsession id's that need it, to
> build a new ScriptBuffer in each
> node in the cluster, and making it available for any poll that is done
> from
> a client to any node.
>
> Do you think that is there any wrong concept?
>
> thanks,
>
> Marc
>
>
>
>
> JoeWalker wrote:
> >
> > I would have thought that the job is simple, but not knowing jgroups I'm
> > almost certainly wrong!
> >
> > The key is these 2 maps which need to be replicated.
> >
> > /* The map of all the known sessions */
> > protected Map sessionMap = new HashMap();
> >
> > /* The map of pages that have sessions */
> > protected Map pageSessionMap = new HashMap();
> >
> > The complexity is probably the lock:
> >
> > protected final Object sessionLock = new Object();
> >
> > Do you need to know any more?
> >
> > You can make your ClusteredSSM work simply by having an init-param with
> a
> > name of the SSM interface, and the value of the implementation.
> >
> > Joe.
> >
> >
> >
> > On 11/8/06, marc <inudor@hotmail.com> wrote:
> >>
> >>
> >> Ok Joe,
> >> we'll start designing something like what I exposed. Any ideas or
> >> suggestions will be welcomed!
> >>
> >> Thanks,
> >>
> >> Marc
> >>
> >>
> >>
> >>
> >>
> >> JoeWalker wrote:
> >> >
> >> > Thanks Marc,
> >> >
> >> > I am aware of this problem. I'd 2 thoughts on how to solve it, one
> was
> >> to
> >> > store everything in sessions (and assume some sort of stickiness or
> >> > session
> >> > replication), and the other to do something like what you suggest.
> >> >
> >> > Please go ahead -  if there is anything you can donate back to us
> then
> >> > great, and please ask for any help.
> >> >
> >> > Joe.
> >> >
> >> > On 11/6/06, marc <inudor@hotmail.com> wrote:
> >> >>
> >> >>
> >> >> Hi all,
> >> >> We are currently developing a project which uses dwr2.0-m3 (haven't
> >> tried
> >> >> m4
> >> >> yet) integrated with spring.
> >> >> We've developed a message notification structure from business layer
> >> to
> >> >> webbrowser, based in ApplicationEvent
> >> >> publications through the ApplicationContext to notify ScriptSessions
> >> >> polling for them, but now we've got a
> >> >> new requisite: deploying the application in a clustered environment.
> >> >>
> >> >> So in the new scenario, events will arise in the business layer of
> any
> >> of
> >> >> the clusters... but our
> >> >> ScriptSessionManager only will know about ScriptSessions directly
> >> >> connected
> >> >> to that node! So... we won't be
> >> >> able to notify sessions connected to other nodes. Even more, we are
> >> not
> >> >> able
> >> >> to use sticky sessions, so when
> >> >> polling, a request could be directed to a node, but the next one
> could
> >> be
> >> >> referenced to another one!
> >> >>
> >> >> So every node in the cluster must be aware of al ScriptSessions and
> >> all
> >> >> published events of all other nodes.
> >> >> This is why we are thinking about designing a
> >> >> ClusterScriptSessionManager,
> >> >> that using jgroups, would notify
> >> >> every node in the cluster about new ScriptSessions, and broadcast
> the
> >> >> addScript info, so any node the request
> >> >> is polled, would now about the pending scripts.
> >> >>
> >> >> What do you think about it? There is a simplier solution perhaps?
> Has
> >> >> someone faced this problem before?
> >> >>
> >> >> Thanks in advance,
> >> >>
> >> >> Marc
> >> >>
> >> >>
> >> >> (excuse me for my english)
> >> >> --
> >> >> View this message in context:
> >> >>
> >>
> http://www.nabble.com/dwr-in-a-clustered-environment%3A-ClusterScriptSessionManager--tf2582194.html#a7198078
> >> >> Sent from the DWR - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@dwr.dev.java.net
> >> >> For additional commands, e-mail: dev-help@dwr.dev.java.net
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/dwr-in-a-clustered-environment%3A-ClusterScriptSessionManager--tf2582194.html#a7234528
> >> Sent from the DWR - Dev mailing list archive at Nabble.com.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@dwr.dev.java.net
> >> For additional commands, e-mail: dev-help@dwr.dev.java.net
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/dwr-in-a-clustered-environment%3A-ClusterScriptSessionManager--tf2582194.html#a7258866
> Sent from the DWR - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@dwr.dev.java.net
> For additional commands, e-mail: dev-help@dwr.dev.java.net
>
>