Re: Tomcat session replicator

[Craig R. McClanahan]

Shai, I apologize for not responding to you earlier ... substantive discussions are getting a little lost in the noise at the moment. For some reason, my Netscape mail reader won't let me intersperse comments -- so I've put them at the end. I think I read into your earlier comment that you'd be interested in being a committer to work on this stuff.  If you're still interested, you've got my +1. Craig   [EMAIL PROTECTED] wrote: Hi, Two weeks ago I posted note here saying I’m going to write patch for Tomcat 3.2 to support redundancy, in manner of having session information stored between reloads and shared between tomcat instances.     In order to support tomcat redundancy I thought on implementing that in two phases: (dumping) While shutting down Tomcat it will save sessions in file and reload them while going up. This feature will allow restarting tomcat without loosing state. (replication) Sending session from one Tomcat to another (AKA: buddy). This will allow the session to have backup on another machine. mod_jk  will send user connection requests to the second machine while the original machine is unavailable. Number 1. above is already implemented, and 2. is going to be finish soon. The question I have is: Should I implement the session replicator listener as stand-alone connector, or incorporate in into Ajpv13? This will require adding two commands to the protocol implementation. Options: Stand-alone connector. This will require another listener. Incorporate it into Ajp13. Incorporate it into Ajp13 and calling it Ajp14. Other ideas? Implementation details will be followed soon. ________________________ Shai Fultheim Chief Technology Officer BRM Seed E-Mail: [EMAIL PROTECTED] Mobile: 972-53-866-459 Office: 972-2-5891-459 The biggest problem I have with integrating session replication into AJPxx is that it means this will only work if you're running Apache connected, versus when Tomcat is running stand alone.  Even in that environment, does the Apache instance really need to know what's going on?  Wouldn't it just be a case of updating the cookie to include the new "router" information when you migrate a session from one JVM to another? Personally, I'd like to see a session migration mechanism that works between the "back end" Tomcat instances.  There are probably few enough of those (in most use cases) that you can maintain a spiderweb of persistent connections that is used only to communicate session migration information. Just as a small technical detail -- the servlet spec says that an application *must* run within a single JVM unless it marks itself as <distributable/> in the deployment descriptor -- don't forget to check for that. As to what version of Tomcat to work on, no matter what the future holds it seems like the current 3.2 code base is not really appropriate for major innovation.  I would only point out that the 4.0 architecture has an interface (org.apache.catalina.Store) behind which session migration stuff can easily be hidden -- as well as support for persistence, swapping, and other advanced features -- without modifying the remainder of the servlet container.  Several other folks have expressed interest in working on this at various times, so collaboration would be quite useful. Craig McClanahan