RE: VOTE: New Commiter Shai Fultheim (was:RE: Tomcat session rep lica tor)

[GOMEZ Henri <hg...@slib.fr>]

+1

I'm very pro the farm concept 

"Pour la plupart des hommes, se corriger consiste à changer de défauts."
-- Voltaire 

>-----Original Message-----
>From: Nacho [mailto:nacho@siapi.es]
>Sent: Friday, December 22, 2000 2:01 PM
>To: 'tomcat-dev@jakarta.apache.org'
>Subject: VOTE: New Commiter Shai Fultheim (was:RE: Tomcat session
>replica tor)
>
>
>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:Craig.McClanahan@eng.sun.com]
>Enviado el: jueves 21 de diciembre de 2000 20:14
>Para: tomcat-dev@jakarta.apache.org
>Cc: danmil@shore.net; costin@locus.apache.org
>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 
> 
>shai@brm.com 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: shai@brm.com
> 
>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 
> 
> 
> 
>