Hello, I was playing around with zero downtime releases since 2003 and I think there are some pitfalls in your approach I dont see yet solved. I'm taking as premise that you are targeting 'larger' sites, meaning loadbalancers, 4++ servers etc. Small sites don't really need this feature imho (the downtime costs are absolutely low).
So, how do you want to handle following: 1. ressources - for the time you have both versions in parallel you'll have double resources need, double amount of db connections, double amount of memory etc. This means that the hosting has to sized accordingly, but hosting on 2times oversized machines just to save some seconds is very expensive. 2. time - the startup of the second instance will usually consume cpu resources. This can make the tomcat unresponsive. If the loadbalancer detects the unresponsiveness it will mark it as unavailable and switch all sessions anyway - nothing won. Usually you will have <30 seconds to perform the startup of the context. 3. end - a release needs an end. Having one user with open browser and continuos refresh shouldn't bind the resources forever. On the other hand, the same behavior is easily achieveable with a bit loadbalancer tuning and Vmware. Are you sure it is worth the effort? regards Leon On Thu, Oct 21, 2010 at 8:52 PM, Mark Thomas <ma...@apache.org> 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
