Re: [PATCH] Tomcat session replicator - Pathces for phase I
Hi Shai, Thanks for your patch, it's a very good start and I think it'll be useful for many users. I think it needs some more work - I'm not talking about the main functionality you are implementing, which I'm sure will be tested and improved and will have a nice evolution. I'm talking as a person who spent a lot of time refactoring tomcat3.x, and ( I hope ) I learned something from it. The most important thing I learned in the last year is: "don't add anything to the core unless you are _absolutely_ sure it can't be done in a module". The reason tomcat3.0 was so bad is that people kept adding new features _in_the_core_ and everything ended up in a total mess. For example: - you can implement the same thing as a new "SerializableSession" module - the new module _doesn't_ have to be part of 3.3 - in fact it's much better to have it as an optional module until it's well tested. - the property you add to Context ( "serialize" ) could be added to the new module ( togheter with other options, describing how and when should serialization happen ) - the user could add the module to his system and add it to the Context he wants - what you do in ContextManager is a perfect example of use of postRequest hook - it'll be part of the SSI.postRequest(). The benefit is that it'll happen _only_ for contexts that need the feature ( instead of adding it to all requetsts - remember, the call to getSession() is expensive, and you'll do it for servlets that never cared for sessions - thus adding overhead for all requests) - your module will be the first session-manager plugin for 3.3. This is where your contribution will be the most important - in figuring out what is the best way to plug a new session manager. My current view is that we need to extend ServerSession, SessionManager and use a different Interceptor - it is possible to do that, but it's still a bit too complex for my taste. Let me say again - what you do in this patch is what I ( and probably most other developers ) would have done to resolve a particular problem. It's what pre-3.0 developers did. If you change it to work as a module you'll have probably a bit more work ( let me know if I can help - after a year of refactoring tomcat I think I can deal with such a small patch in a very short time :-). The benefits: - no change in the core - keep it simple - it can evolve independently of tomcat release cycles - as you know after 3.3 is out ( inside or outside apache ) we want to avoid any further changes. You module may evolve quickly - there are many ideas to explore. - you don't need to argue with people like Jon about it :-) - it doesn't have to be part of tomcat3.3, it's an add-on module. In general, there is no need to argue with anyone - if the modules is good for you, I'm sure other will like it, and who doesn't like it is free not to use it. - there is more than one way to do it - other ideas could be developed, maybe we would want to serialize the session periodicaly ( not per/request), or use a MM-like system, etc - by not adding the changes to ContextManager but in the postRequest hook we could have any combination of those. What do you think ? Costin P.S. - finally a technical issue - I will not answer to anything else. - I'm reading my own mails, and I'm amazed about how much I wrote in the last weeks (about almost nothing :-). Since it doesn't happen to me too often ( to write a lot of "english" ) I'll try to refocus it into improving the "internal" documentation of tomcat 3.3 :-)
Re: [RFC] Distributed sessions in Catalina
I have a bit of fear that you're getting into extremely complex waters here, and I want to be sure you focus on the most useful bits first. Any form of distributed synchronization of data is very difficult to get right, IMHO. Which is not to say that it shouldn't be done, nor that your ideas below are off base, but rather that I would vote for focusing on a smaller piece of the puzzle first. For example, maybe fault tolerance is what seems most important (I think this would be my vote). Then you can look at distributed sessions as being about: - Allowing Tomcat instance A to back up session information to Tomcat instance B - Configuring whatever device is load-balancing among Tomcat instances to know that it should reroute A's session to B if instance A becomes unavailable. (Incidentally, Shai Fultheim is working on this problem at the moment -- he's at [EMAIL PROTECTED]). This would be a good-sized (but manageable) bit of work, and would provide a very important piece of functionality. It takes advantage of the existing solutions which make sessions sticky to a particular tomcat instance (e.g. mod_jserv/mod_jk load balancing, router-level solutions, etc). If you do allow multiple TC instances to update a given session at once, you have to worry about all sorts of hairy concurrency issues. Two requests from the same session could come in simultaneously (from a framed site, for example). If one goes to A and one goes to B, and both A and B try to update the session at the same time, the code to handle that is going to be very complex. The other main goal you cite is "improving performance by distributing load". Given that there are currently several ways to make sessions sticky to particular TC instances, I'm not sure how much work I would put towards that goal. So I guess my summary is that I see session replication in support of fault tolerance as very worth working towards, but a more general form of session replication as someting to hold off on. -Dan -- Dan Milstein // [EMAIL PROTECTED]
RE: [RFC] Distributed sessions in Catalina
I think someone already has been assigned to implement a session store for javaspaces. Check out the action items for Catalina. Dave --- Brett Bergquist [EMAIL PROTECTED] wrote: Keif, have you considered using JavaSpace's as a shared storage mechanism. I've just read some things on this and it seems like it might be a fit, but I've not played with this yet. Just a thought. BTW, there is a good article on this in one of the fairly recent Java Developer's Journal. -Original Message- From: Kief Morris [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 24, 2000 11:57 PM To: [EMAIL PROTECTED] Subject: RE: [RFC] Distributed sessions in Catalina [EMAIL PROTECTED] typed the following on 11:16 PM 12/24/2000 +0200 I'm planning to implement session replication (for tomcat 3.3) in the following steps: Sounds like we should combine efforts, hopefully we can share as much code as possible across both 3.3 and 4.0. My understanding is that the architecture between the two is pretty different, and I've only looked at 4.0 to any depth. 1. Having persistent session store. Letting tomcat store its session information to file and read it while coming up. Saving session will happen as soon as request will be finished. - This will let us restart tomcat without loosing sessions. Sounds like a good option. Catalina saves sessions to file when the container is restarted, it should be pretty easy to use that code to implement this. Have you had a look at it? Check out jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardMa nager.java, in particular the load() and unload() methods. 2. Let Tomcat send session information (for every request) to all other tomcat in a cluster. This will let apache (using mod_jk) to forward requests to other tomcats after finding out that the original tomcat (by jvmRoute) is not answering). - This will let us have redundancy into tomcat. Still we will need apache (mod_jk) in the picture. How are you thinking to implement this? There are different network topologies I could see using. If the servers share a file system, we could just use the file store you describe in step 1. This would be simpler to implement, but using the network and keeping the session data in memory could be faster than using the disk. 3. Letting tomcat forward requests to another tomcat based on jvmRoute. - This will let us having Tomcat without Apache around. The tomcat will be load balanced using external system (Local Director?), and forward requests to the relevant instance. How will tomcat forward requests? Will it issue a redirect to the browser, or will it proxy the connection? Either way seems like unnecessary overhead. If you implement the session sharing in step 2, there should be no need to forward requests - whichever instance of tomcat gets the request should be capable of handling it. You're actually moving a bit ahead of where I am at the moment. I'd like to define an interface which will allow the implementation of different methods for session sharing. A lot of the things you're doing would go into specific implementations, but some implementations might require a different, incompatible approach. I'll chew on this some more, will try to get some code out between family xmasing duties (am I sad or what?) Kief --- Kief Morris Director of Technology bitBull Ltd. http://www.bitBull.com phone +44 020 7598 9938 fax +44 020 7460 4081 . tBull Ltd. http://www.bitBull.com phone +44 020 7598 9938 fax +44 020 7460 4081 . __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
