Hi, I'm looking at the same area at the moment. and try to get my head around it.... maybe we can help each other... further comments below.
----- Original Message ----- From: "Tom Drake" <[EMAIL PROTECTED]> To: "Tomcat Dev List" <[EMAIL PROTECTED]> Sent: Monday, November 12, 2001 11:19 PM Subject: Fw: Tomcat: Distributed Session Management revisited > Tomcat Developers: > > This is a forward of a message that I sent to Bip and Craig a few days ago, > regarding distributed session managment (aka Clustering). I haven't gotten > any feedback just yet, so I thought I'd throw this out to the whole dev > list. > > The current implementation is broken. The following message explains > why and describes some possible solutions to this problem. > > This feature (e.g. distributed session management) is an absolute > requirement > for any deployment that needs to scale beyond a single Tomcat instance, and > does not want the overhead of depending on JDBC for storing sessions. > > I've also attached, at the bottom of this message, Two 'preliminary' RMI > interfaces > that describe (see scenario 1 below) how I think this session server and > it's > clients (e.g. tomcat instances) should converse. > SessionServer - to be implemented by the remote session manager/server > SessionClient - to be implemented by clients (e.g. Tomcat) of the remote > session manager/server. > > I'm interested in making a contribution in this area and am anxious to > receive > some feedback from the dev-list members on this subject. > > Regards, > > Tom Drake > Email: [EMAIL PROTECTED] > > > ----- Original Message ----- > From: Tom Drake > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Sent: Saturday, November 10, 2001 10:48 PM > Subject: Tomcat: Distributed Session Management revisited > > > Bip: > > I've looked closely at the existing catalina distributed session > management code, and determined that the following problems > exist. Since, I'm new to the code, it's highly likely that I've missed > something. Please correct any errors in my analysis, and provide > any input / feedback. I'm interested in contributing to this and would > greatly appreciate any input you can provide. > > Problems with current solution: > > - Session updates are not communicated to the other nodes in the cluster No, session updates are frequently communicated to all other cluster members through the DistributedManager.run() method [processPersistenceChecks();]. ... a second look came up with that only idle sessions and overflow sessions are replicated... Anyway, that's a paradigm-thing... how accurate does a session need to be? After every change or just every couple of seconds. Should be configurable. <...> I would vote for the cooperative approach, but I'd like to add some thoughts: Besides the primary session manager, there needs to be a backup session manager that captures the changes of sessions as well and is the crown prince of the primary session manager. This is to prevent sessions to be replicated to all other cluster instances (memory overhead) but to stay on the save side if the primary goes down (yep, both could crash, but what in live is 100%?). In that case the crown prince would take over and another cluster instance can take over the crown prince's role. Which server the primary manager is, should be either configurable or random. The cluster instances should be configurable. Multicast should only be used if the cluster instances are not configured to find out what other instances are there. The configuration should only specify the initial state, further instances should be addable at any time without the need to bring the cluster down. Another thought is, do sessions need to be replicated in whole, or could there be a way to replicate only the changes (network overhead). I know guys that store loads of things in sessions. We had a case where a whole search result (one complex object per row) was stored there, possibly up to a couple of megs... RMI would be my first approach as well, but I would try to keep the communication details separated from the functional logic implementing the cluster. This would enable us later on to choose other means like JavaSpaces or JMS. RMI is the first choice if the cluster is near by, but what against a cluster over a WAN if the requirements allow slow/deferred replication? RMI could not do that job reliable. Cheers, Mika ^X^C -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
