geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: Web Clustering : Stick Sessions with Shared Store
Date Fri, 17 Oct 2003 11:34:59 GMT
this sort of flexibility is high on the list


Michael Barker wrote:

>Would it be possible to have a pluggable Web Clustering layer? 
>Different users may want to have different configurations depending on
>their implementation.
>E.g. In-memory replication (perhaps via a non-persistent message on an
>HA JMS system) would work quite well on a small cluster (2-4 nodes) as
>there would not be that much more network traffic and each node would
>only have to hold 2-4 times as many http sessions as there are currently
>associated to that node.  It would not scale up to a larger cluster
>though, as amount of memory required to store the sessions and the
>network traffic to replicate them would become unwieldy, therefore DB
>persistence would work better in this case.
>Also hybrid solutions (similar to the one below) could be created by
>enabling sticky sessions (with fail-over if unavailable) and cached DB
>If I was architecting a solution I know I would like to able to select
>the optimal clustering solution for my configuration.
>Just my 2c.
>On Thu, 2003-10-16 at 20:50, Bhagwat, Hrishikesh wrote:
>>hi all,
>>I was going through the Architecture Notes for Web Clustering (
I do not have much experience with these things ... none the less here is an approach i did
like to suggest.
>>PLEASE SEE THE jpeg image (inline -text based images get distorted when seen through
different mail-clients)
>>All ref. below are from the doc. mentioned in the hyperlink above
>>*  A particular session is associated with exactly one Node (Managed Server - MS).

>>*  Any change to the session will be written to the DB by the corresponding node.
However unlike what has been mentioned in section 1.1.1, the session WILL NOT BE       POPPED
OUT OF MEMORY between two HTTP requests. It will continue to stay there (in memory) so that
subsequent requests can be serviced quickly. (The only reason to write it to the DB is that,
in case this node fails, another node can pick up the session-info from the DB.)
>>* Now if this node becomes unavailable the, the ADMIN SERVER will distribute its clients
to other MSs. Each MS will thus get a subset of Clients, of the server, that just went down.
>>* An MS can then query the DB and get the Session object (updated to the last activity)
for each of its newly acquired clients.
>>1. Does not suffer from Single Point Of Failure
>>2. Easy to implement. No broadcasting or session-duplication issues. etc. (No need
for a messaging system). 
>>3. With a little intelligence built in an MS can store away, less busy sessions to
DB and retrieve them when needed 
>>    thus offering something that is near to "virtually unlimited amount of sessions
>>4. On fail over the algo to distribute the clients can be relatively simple. Probably
use round robin. Say X and Y are
>>    clients for MS1(which has just failed).
>>    client 'X' makes a request, the ADMIN Server can direct that to MS2 and then simply
updates its (ADMIN_SERVER's) internal Data structures 
>>    to say 'X' belongs to MS2 . Then a request from 'Y' comes in it to MS3
... etc
>>5. Since no MS knows about no other MS, implementing the MS and ADMIN SERVER would
be simpler. ( I think that the concept of Primaries and Secondaries
>>    is rather difficult to implement).
>>6. Does not create unnecessary Broadcast traffic (needed otherwise for Session data
>>1. Need to write the session to the DB for every request.
>>Awaiting comments.
>> <<cluster.jpeg>> 

 * Jules Gosnell
 * Partner
 * Core Developers Network (Europe)

View raw message