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. > 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. > 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. > 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. > Are you sure it is worth the effort? Yes. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
