geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bhagwat, Hrishikesh" <hbhag...@visa.com>
Subject Web Clustering : Stick Sessions with Shared Store
Date Thu, 16 Oct 2003 19:50:15 GMT
hi all,

I was going through the Architecture Notes for Web Clustering (http://wiki.codehaus.org/geronimo/Architecture/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.

Advantages:
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 (section
1.1.1.1)"
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 ...direct 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 replication)

Disadvantages
1. Need to write the session to the DB for every request.


Awaiting comments.
-hb
 <<cluster.jpeg>> 






Mime
View raw message