I discovered this feature a while ago in Weblogic and I found this interesting. But as I always had classloader leaks, I had to restart the JVM anyway so that it defeated the purpose of the feature and I gave up dreaming of zero-downtime deployments. Now with tomcat memory leak protection features, this deployment option might be once again very interesting.
Though I can see how this can be done for a standalone tomcat instance, how do you plan to do with clustered sessions ? Should the old version of the application wait for all sessions in the cluster to expire ? Sylvain On 21 oct. 2010, at 20:52, Mark Thomas wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
