Re: dwr in a clustered environment: ClusterScriptSessionManager?

by marc :: Rate this Message:

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
>
>

« Return to Thread: dwr in a clustered environment: ClusterScriptSessionManager?