+1
Costin
On Fri, 22 Dec 2000, Nacho wrote:
> 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
>
>
>
>
