Shai has contributed great bug fixes ( one specially difficult in 3.2,
thanks Shai ) and he wants to contribute a distributed session manager
It has been proposed as committer by Craig in a informal way, now it's
proposed in a formal way :-)
it has my +1 as well +1 from Craig in the message below.
Votes , please.
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Enviado el: jueves 21 de diciembre de 2000 20:14
Para: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Asunto: Re: Tomcat session replicator
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 Im 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:
1. (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.
2. (replication) Sending session from one Tomcat to another (AKA:
buddy). This will allow the session to have backup on another machine.
mod_jkwill 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:
1. Stand-alone connector. This will require another listener.
2. Incorporate it into Ajp13.
3. 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
