Re: dwr in a clustered environment: ClusterScriptSessionManager?

Hi Marc and Joe,

We are facing the same issue. It seems from this discussion-thread that
there were plans to develop a solution. Has there been any progress? Is
there anything you can share?

Thanks,
Naaman




marc wrote:

>
> Hi Joe,
> our approach about using our own DWRServlet was in order to initialize the
> JBoss channel, and yes, we could do it as another component registered in
> the Container, but the object must have some lifecycle control, to be able
> to destroy de channel correctly when undeployed.
>
> This is why we bind our HAManager to the servlet, to use its lyfecicle.
>
> We'll study this problems about locking.
>
>
> Marc
>
>
> 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@...> 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@...> 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@...> 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@...
>>> >> >> For additional commands, e-mail: dev-help@...
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> 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@...
>>> >> For additional commands, e-mail: dev-help@...
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> 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@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/dwr-in-a-clustered-environment%3A-ClusterScriptSessionManager--tf2582194.html#a9713490
Sent from the DWR - Dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...