You describe a good solution. Is there a way to have multiple versions of an application on one server, as opposed to having to divide up versions of the application per server?
I ask because if your users tend to have long sessions, then in the Tomcat cluster you'd like to disable you could be waiting hours for all those sessions to die, in which case you're "wasting hardware" and overburdening the version of the server with your new application. I'm hoping there's a way to do this... Thanks. Tim Lucia wrote: > > At my company, we have a weekly application update. Sometimes it is more > frequent than that. We have Apache/httpd + mod_jk and three clustered > Tomcats. Updating the Tomcats one at a time causes no loss of service as > the other two pick up. Of course we do this during the periods of lowest > usage, and you cannot get away with incompatible session attribute > changes. > I have an "ant deploy" rule which iterates over a list of Tomcat hosts and > undeploys-the-old/deploys-the-new using the Tomcat manager / deploy tasks. > > One alternative is to use mod_jk (or load balancer / traffic router of > your > choice) to partition the Tomcats in to 2 clusters: TC1 and TC2 > > TC1 has V2.0.5 of /yourapp > TC2 has V2.0.6 of /yourapp > > Enable/start the workers on TC2 > Disable each worker on TC1 and wait for the count to go to zero > > Upgrade TC1 to V2.0.7 of /yourapp > Move traffic from TC2 to TC1 > > I've tested the latter and it worked during testing, but we've not had > sufficient need to make use of it in production. > > HTH, > Tim > > >> -----Original Message----- >> From: lightbulb432 [mailto:[EMAIL PROTECTED] >> Sent: Thursday, April 26, 2007 1:03 AM >> To: users@tomcat.apache.org >> Subject: Seamless transition between application updates >> >> >> What are the strategies you might use to update an application running on >> multiple Tomcat instances (clustered with Apache mod_jk) with a seamless >> transition for somebody who's using the application at the time the >> application is redeployed? I've always wondered how web applications that >> cannot afford downtime do it. >> >> In my naive understanding I'd simply shut off all servers, redeploy the >> updated applications, then turn all the servers back on. In this case, >> it's >> pretty straightforward to understand what would happen. However, users >> would >> experience downtime (or at least a non-seamless transition). In >> environments >> that have requirements not to make users relogin everytime a change is >> made, >> how would applications that provide smaller, more frequent updates >> survive? >> >> How would you go about doing this, specifically, in a clustered Tomcat >> environment? What things should I keep in mind when figuring out how to >> best >> do this? >> >> Problems that I foresee include someone who's POSTing from his current >> page >> to a just-updated version of a servlet on Tomcat...in this case, what the >> user expects to happen might not be what is expected, due to the servlet >> update. In the best case the user has to relogin due to an error. In the >> worst case the operation goes through successfully but modifies the data >> in >> some unexpected way. >> >> Your insight on this matter is greatly appreciated. >> -- >> View this message in context: http://www.nabble.com/Seamless-transition- >> between-application-updates-tf3649567.html#a10194118 >> Sent from the Tomcat - User mailing list archive at Nabble.com. >> >> >> --------------------------------------------------------------------- >> To start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Seamless-transition-between-application-updates-tf3649567.html#a10434931 Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
