On Fri, Oct 22, 2010 at 3:04 PM, Mark Thomas <ma...@apache.org> wrote: > On 22/10/2010 13:28, Leon Rosenberg wrote: >> Hello, >> >> I was playing around with zero downtime releases since 2003 and I > This isn't zero downtime. Tomcat already does that and has done for > quite a while. This handles the case where sessions from version n can't > migrate to version n+1 - e.g. to an incompatible change in the classes > used for persisting data in the session. > >> 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). > This is aimed at all sites - large and small. > >> 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. > You'll only need double the resources if you have double the load. That > won't be the case. The load will remain the same, just distributed > across two web applications rather than a single one. There will be the > increased permgen demands of an additional application deployed but that > is usually a relatively small percentage of the overall memory requirements.
Well the primary resource I see as a problem is heap. I have one customer who runs his tomcats with 12gb heap and another with 8. Both do that on 16 gb machines. They couldn't increase without resizing the machines. The heap is really used and not for session related content but for global caching etc. > >> 2. time - the startup of the second instance will usually consume cpu >> resources. This can make the tomcat unresponsive. > I have never seen an app do that. Context initialization happens on a > single thread so at the absolute worst, one thread will be consumed but > that is only going to happen with an app that has a cpu intensive start-up. >> 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. > Context start-up can take as long as it likes. Requests won't get routed > to the n+1 version of the context until it has started. Ok, I have experience with some very heavy start applications - basically they produce 100% cpu load for 1-2 minutes, this can decrease the performance of other requests, but this is surely not a common rule for all applications. > >> 3. end - a release needs an end. Having one user with open browser and >> continuos refresh shouldn't bind the resources forever. > So undeploy the old version of the app. That will force the switch. We > could easily make that happen automatically after a configurable delay. Sounds very well. > >> On the other hand, the same behavior is easily achieveable with a bit >> loadbalancer tuning and Vmware. > Not sure why VMware is a requirement. Yes, you can achieve the same aim > with multiple instances and a load-balancer. However that requires much > more plumbing than just deploying a WAR and won't work with the existing > tool-sets for deployment (Ant, Maven, manager app, home grown etc.) > without a fair amount of additional custom code to co-ordinate the > multiple instances and the load-balancer config. I found many operations-manager to be extremely resistant against "fancy-java-features" and having a "we-can-do-it-better-with-vi"-attitude :-) This could be an experience related to my geographic location ;-) > >> Are you sure it is worth the effort? > Yes. :-) regards Leon --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
