Hi, I’m still
interested in being committer. I do agree
on your assessment regarding the off-apache session replication. This will
give us the ability to create stand-alone tomcat cluster, while letting tomcats
transfer users requests from instances to instance by container’s load. We will
like to have all working without Apache around. So we can still use Ajp code to
move http requests from one container to another. So in that case why not to
implement it into ajp. ??? --Shai -----Original
Message----- 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,
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_jk will send user connection requests to the second machine while the
original machine is unavailable. 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. Shai Fultheim Chief Technology Officer Mobile: 972-53-866-459 Office: 972-2-5891-459
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 |
- Re: Tomcat session replicator Craig R. McClanahan
- Re: Tomcat session replicator Jason Brittain
- Re: Tomcat session replicator Craig R. McClanahan
- Re: Tomcat session replicator Jason Brittain
- Re: Tomcat session replicator cmanolache
- Re: Tomcat session replicator [EMAIL PROTECTED]
- Re: Tomcat session replicator Craig R. McClanahan
- Re: Tomcat session replicator Jason Brittain
- Re: Tomcat session replicator [EMAIL PROTECTED]
- Re: Tomcat session replicator [EMAIL PROTECTED]
- RE: Tomcat session replicator shai
- RE: Tomcat session replicator GOMEZ Henri