dwr in a clustered environment: ClusterScriptSessionManager?

[marc]

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)

[JoeWalker]

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

[marc]

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 <[e-mail]> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[JoeWalker]

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

[marc]

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 <[e-mail]> 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 <[e-mail]> 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: [e-mail]
> >> For additional commands, e-mail: [e-mail]
> >>
> >>
> >
> >
>
> --
> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[JoeWalker]

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

[marc]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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: [e-mail]
> >> >> For additional commands, e-mail: [e-mail]
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> 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: [e-mail]
> >> For additional commands, e-mail: [e-mail]
> >>
> >>
> >
> >
>
> --
> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[nlif]

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




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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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: [e-mail]
> >> >> For additional commands, e-mail: [e-mail]
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> 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: [e-mail]
> >> For additional commands, e-mail: [e-mail]
> >>
> >>
> >
> >
>
> --
> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Joe Walker-3]

I don't know of any progress on this front.
I'm planning to get a Terracotta integration working as a solution for a demo at JavaOne.

Joe.

On 3/28/07, nlif <naaman@...> wrote:

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

[nlif]

Thanks, Joe.
Do you mean you'll be using Terracotta just for the demo? Do you have any plans for adding clustering support to DWR (using JGroups, or simply rely on HttpSession replication)? Assuming one doesn't already use Terracota for other purposes, isn't it an overkill?

My main reason for asking, is that I'd like to know whether it's worth waiting for a while for a DWR built-in support, or to go ahead and develop something myself.

Thanks again,
Naaman

Joe Walker-3 wrote:

I don't know of any progress on this front.
I'm planning to get a Terracotta integration working as a solution for a
demo at JavaOne.

Joe.