All, As most of you are probably aware I work for SpringSource and SpringSource has an application server product - tc Server - that is heavily based on Apache Tomcat. When talking to prospective clients about tc Server, one of the things we often hear is "WebSphere/WebLogic has XYZ feature - does tc Server?" and one of those features is parallel deployment.
Parallel deployment is essentially having two (or more) versions of the same application deployed side-by-side. Users with a session in an older version, will continue to use that older version until the session expires. Users without a session, or whose session expires, will use the latest version. Once there are no sessions using the older version it is undeployed. All versions of the application have the same context path so the transition is seamless to the users. Having looked at some implementation options, it quickly became apparent that Tomcat was the right place to implement this rather than as an 'add-on' in tc Server. I have managed to convince senior management that contributing an implementation of parallel deployment to the ASF is the way to go. I currently have a hacked together implementation [1] that works but is very ugly in places under the covers and there is still some significant work to go before it is robust enough to be put into trunk (it changes the mapper and that is an area I think we need to be very careful). A lot of the patch is dealing with the issues around the fact that we currently treat Context.getPath() and Context.getName() as the same thing but with parallel deployment these need to be treated differently. My proposal is therefore: - start committing some of the getPath() / getName() clean-up to trunk along with some of the other hooks - like adding a version attribute to Context that should be minimal risk - continue testing the current patch (e.g. with clustering) and modify as required - discuss the implementation details (like the file naming convention used) on the dev list - decide once we can see the patch without the clean-up if it is safe for 7.0.x or needs to be held back for 7.1.x Depending on how big this patch ends up looking then creating a branch for this work may make sense. I'd like to hold off creating a branch for a few days until the clean-up changes have been made to trunk so the branch can focus on the diffs required for the new feature. As always, any and all feedback welcome. Mark [1] http://people.apache.org/~markt/patches/2010-10-21-parallel-deployment.patch --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
