+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:[EMAIL PROTECTED]] >Sent: Friday, December 22, 2000 2:01 PM >To: '[EMAIL PROTECTED]' >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:[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 > > > >
