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