geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: WADI clustering
Date Tue, 17 Jan 2006 17:41:36 GMT
Rajith Attapattu wrote:

>  Hi,
> Some of these questions came up after reading the thread on totem. 
> However I started the new thread so that searching is easy and also 
> want distract the intense discussions on totem with out-of-topic 
> questions.
> Jules Gosnel wrote
> >This is not something that is really considered a significant saving in
> >WADI (see my last posting's explanation of why you only want one
> >'active' copy of a session). WADI will keep session backups serialised,
> >to save resources being constantly expended deserialising session
> >backups that may never be accessed. I guess actually, you could consider
> >that WADI will do a lazy deserialisation in the case that you have
> >outlined, as primary and secondary copies will actually swap roles with
> >attendant serialisation/passivation and deserialisation/activation
> >coordinated by messages.
> >If you are running a reasonable sized cluster ( e.g. 30 nodes - it's all
> >relative) with a small number of backups configured (e.g. 1), then, in
> >the case of a session affinity brekdown (due to the leaving of a
> >primary's node), you have a 1/30 chance that the request will hit the
> >primary, a 1/30 that you will hit the secondary and a 28/30 that you
> >will miss :-) So, you are right :-)
> So just to figure out if I understand this correctly.
> 1.) WADI only has one active and one-two backups at most (I assume the 
> no of backups is configurable)

replication is under implementation at the moment. Any number of backups 
should be configurable, but the more you have the less performant you 
are. You trade off safety for speed.

> 2.) WADI is built up on the assumption of session affinity. So the 
> probability of missing the primary and the secondary backup(s)  goes 
> up as the cluster grows according to your example

WADI will work without session affinity, however, as you would expect, 
this will not perform as well as it might. If you switch on affinity, 
you will drastically cut down the amount of request/session relocation 
and most interactions should become local.

Switch off affinity, and of course, your chances of hitting a copy of 
the session will go down. There are a fixed number of sessions and you 
are increasing the number of nodes... If you are intending to use an lb 
without affinity, then you should really reconsider. The costs are tiny 
and the gains enormous. Affinity is a standard feature on any serious 

> 3.) How does WADI handle a situation where there is no session affinity??

If a request lands on the primary, processing occurs locally.
If a request arrives at a secondary, primary and secondary swap roles 
and processing happens locally.
If a request arrives on a node with no copy of the relevant session, it 
may be relocated to the primary, or the primary to it.

> 4.) Have you compared the overhead of maintaining session affinity vs 
> having R replicas (all-Active) to service the client.

I have worked on impls using both approaches and am satisfied that my 
most recent approach will be the most performant.

> >If, however,  you did your deserialisation of replicants up front and 
> thus avoided further messages when a secondary was hit, by maintaining
> >all copies 'active' (I think you would not be spec compliant if you 
> did this),
> 1.) What do u mean by spec here ?? Are u talking about the WADI spec?

There is no WADI spec :-) - I'm talking about the servlet spec - 
specifically :

SRV 7.7.2 - "Within an application marked as distributable, all requests 
that are part of a session must be handled by one Java Virtual Machine1 
( JVM ) at a time." and "Containers must notify any session attributes 
implementing the HttpSessionActivationListener during migration of a 
session. They must notify listeners of passivation prior to 
serialization of a session, and of activation after deserialization of a 

These two constraints make it, IMHO, much more difficult to try 
implementing any system that maintains multiple 'active', or 'primary' 
copies of a session. The system needs to be absolutely clear where the 
single 'active' copy is at any one time, in order to remain compliant. 
To ensure that activation/passivation semantics work OK, only this 
session may be activated, whilst the other 'secondary' copies are 
passivated. By leaving the secondaries in serialised form, you save 
further cycles and arrive at WADI's current design.

> 2.) Assuming sombody wants to do session replication (All 
> Active) instead of (one Active and "n" backups) is there provision 
> within the WADI api to plug in this stratergy?

I'm giving this some thought in terms of SFSB support, I'm not aware of 
similar constraints in the EJB world...

I guess we could relax this constraint in the web world, but I am not 
sure that I think that this is a good idea. Can you see a way to do this 
and maintain spec compliance and performance ?

> If u remeber we talked about extention points within WADI.
> 1.) Is there a doc that describes WADI architecture

Not as yet, just a website with various resources hanging of it. WADI is 
still relatively young. The best source of architecture info is the 
conversations that we have been having.

> 2.) Is there a doc that describes these extention points and how to do 
> it?? (Looking for a little more info than the API doc)

WADI is put together using Spring. You just check out the javadoc and 
plug the pojos together. A lot of what we have been talking about is 
architectural design and not implemented (although the primary/secondary 
stuff is all in and working).



> Thanks,
> Rajith.

"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)
 * Open Source Training & Support.

View raw message