dwr in a clustered environment: ClusterScriptSessionManager?

[baris]

Hi Joe,

We have  a dwr application and we also need a load balancing solution,

Among the alternatives I think Terracotta seems to be a promising solution but did not start testing yet! the most significant value to add will be handling things at the low level and keeps dwr from the complexity of session management, I hope.

Can you tell your experience with it and highlight any issues you met,if  you had the integration?

Did anybody give a try to terracotta on  dwr+spring?

Thanks

Baris

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.

On 3/28/07, nlif <[e-mail]> 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 <[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]
> >>>
> >>>
> >>
> >>
> >
> >
>
> --
> 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: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Joe Walker-3]

Steve - do you know what the status is of the Terracotta/DWR integration?
I think it would be a good idea for us to include the source with DWR - whenever someone wants clustering support, it makes it fairly clear where to go.
Thanks,

Joe.

On 11/1/07, baris <javaceylan@...> wrote:

Hi Joe,

We have  a dwr application and we also need a load balancing solution,

Among the alternatives I think Terracotta seems to be a promising solution
but did not start testing yet! the most significant value to add will be
handling things at the low level and keeps dwr from the complexity of
session management, I hope.

Can you tell your experience with it and highlight any issues you met,if
you had the integration?

Did anybody give a try to terracotta on  dwr+spring?

Thanks

Baris


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

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

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

[sharrissf]

Hey Joe

I don't think it's been looked at in a while. It would be great to include it with your source so that it gets moved forward with your code and gets the proper attention. 

Now day we tend to package such integrations as "Terracotta integration modules" so it would be a good idea to wrap it up as one of those (we can help with that).

Another option is that we are building a "forge" where integrations like this can be placed and get tested and published to a maven repo as "Terracotta Integration Modules" You could then use ivy or maven to auto pull it into your environment. Anyway, let me know which you prefer we are happy to help what ever way you want to go.

Cheers,

Steve

On Nov 2, 2007, at 8:06 AM, Joe Walker wrote:

Steve - do you know what the status is of the Terracotta/DWR integration?
I think it would be a good idea for us to include the source with DWR - whenever someone wants clustering support, it makes it fairly clear where to go.
Thanks,

Joe.

On 11/1/07, baris <javaceylan@...> wrote:

Hi Joe,

We have  a dwr application and we also need a load balancing solution,

Among the alternatives I think Terracotta seems to be a promising solution
but did not start testing yet! the most significant value to add will be
handling things at the low level and keeps dwr from the complexity of
session management, I hope.

Can you tell your experience with it and highlight any issues you met,if
you had the integration?

Did anybody give a try to terracotta on  dwr+spring?

Thanks

Baris


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

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

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

[Joe Walker-3]

I would certainly like it in the DWR source tree so we get to see if it is affected by any refactoring. I don't really care how it gets there, but I would like some sort of a CLA to say that it's allowed to be there. I'm sure you have a similar thing as part of Terracotta. My CLAs are here: http://getahead.org/dwr/development/contributor

If you have clearly published it under an Apache license than this may do in place of a CLA though - I'm not sure. Do you have any experience of this?

Thanks,

Joe.

On 2 Nov 2007, at 15:36, Steven Harris wrote:

Hey Joe

I don't think it's been looked at in a while. It would be great to include it with your source so that it gets moved forward with your code and gets the proper attention. 

Now day we tend to package such integrations as "Terracotta integration modules" so it would be a good idea to wrap it up as one of those (we can help with that).

Another option is that we are building a "forge" where integrations like this can be placed and get tested and published to a maven repo as "Terracotta Integration Modules" You could then use ivy or maven to auto pull it into your environment. Anyway, let me know which you prefer we are happy to help what ever way you want to go.

Cheers,

Steve

On Nov 2, 2007, at 8:06 AM, Joe Walker wrote:

Steve - do you know what the status is of the Terracotta/DWR integration?
I think it would be a good idea for us to include the source with DWR - whenever someone wants clustering support, it makes it fairly clear where to go.
Thanks,

Joe.

On 11/1/07, baris <javaceylan@...> wrote:

Hi Joe,

We have  a dwr application and we also need a load balancing solution,

Among the alternatives I think Terracotta seems to be a promising solution
but did not start testing yet! the most significant value to add will be
handling things at the low level and keeps dwr from the complexity of
session management, I hope.

Can you tell your experience with it and highlight any issues you met,if
you had the integration?

Did anybody give a try to terracotta on  dwr+spring?

Thanks

Baris


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

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

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

[sharrissf]

Cool, let me check into that. I'm pretty sure we have no problem donating what ever part of the dwr integration that we did so it's just a matter of dotting the i's and crossing the T's.

In fact, we absolutely prefer owners of frameworks to also own the Terracotta integration.

I'll look into it and try to get back to you some time later today. That code wasn't part of our product so I'm not sure what the "Official rules" are for code

we did that isn't part of our product. BTW, if you use maven for dwr, you can now use our maven repo to auto-pull terracotta for your testing infrastructure

at runtime.

Cheers,

Steve

On Nov 2, 2007, at 8:48 AM, Joe Walker wrote:

I would certainly like it in the DWR source tree so we get to see if it is affected by any refactoring. I don't really care how it gets there, but I would like some sort of a CLA to say that it's allowed to be there. I'm sure you have a similar thing as part of Terracotta. My CLAs are here: http://getahead.org/dwr/development/contributor

If you have clearly published it under an Apache license than this may do in place of a CLA though - I'm not sure. Do you have any experience of this?

Thanks,

Joe.

On 2 Nov 2007, at 15:36, Steven Harris wrote:

Hey Joe

I don't think it's been looked at in a while. It would be great to include it with your source so that it gets moved forward with your code and gets the proper attention. 

Now day we tend to package such integrations as "Terracotta integration modules" so it would be a good idea to wrap it up as one of those (we can help with that).

Another option is that we are building a "forge" where integrations like this can be placed and get tested and published to a maven repo as "Terracotta Integration Modules" You could then use ivy or maven to auto pull it into your environment. Anyway, let me know which you prefer we are happy to help what ever way you want to go.

Cheers,

Steve

On Nov 2, 2007, at 8:06 AM, Joe Walker wrote:

Steve - do you know what the status is of the Terracotta/DWR integration?
I think it would be a good idea for us to include the source with DWR - whenever someone wants clustering support, it makes it fairly clear where to go.
Thanks,

Joe.

On 11/1/07, baris <javaceylan@...> wrote:

Hi Joe,

We have  a dwr application and we also need a load balancing solution,

Among the alternatives I think Terracotta seems to be a promising solution
but did not start testing yet! the most significant value to add will be
handling things at the low level and keeps dwr from the complexity of
session management, I hope.

Can you tell your experience with it and highlight any issues you met,if
you had the integration?

Did anybody give a try to terracotta on  dwr+spring?

Thanks

Baris


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