-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lightbulb,
lightbulb432 wrote: > 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. The biggest problem isn't the code, it's the other stuff that needs to be upgraded. Tim describes a good way to upgrade app servers incrementally, but doesn't say anything about a database. Usually, a major upgrade involves changes to a database which are incompatible with the old version. Crafting a deployment plan to upgrade the database and the application in phases is challenging. The process of upgrading Tomcat instances in a cluster is much easier. Note that anyone who /was/ using the old version and suddenly finds themselves using the new version of the application might get ClassCastExceptions or something similar if your session objects do not have fixed serialVersionIDs. > 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. You probably want to herd users over to a set of servers that will continue to run the old version for a while. Basically, disable logins on that server and direct all new mod_jk traffic to the "old" app servers (not sure how to do this... you'll have to ask the mod_jk gurus, or consult your load balancer documentation). After the users die down on the servers marked for the first upgrade, go ahead and upgrade their code. Then, re-enable new traffic to the upgraded server. All of the old sessions should still point to the old server (if you are using session affinity, which will really help during this process). Now, disable logins on the old servers and eventually they will go idle. At that point, you can upgrade the remaining servers. You can basically do this in as many phases as you want, so if you have 15 machines, maybe you want to upgrade 5 at a time. Again, my biggest worry would be if there are any significant incompatibilities between code versions and their dependencies (such as database structure, etc.). Hope that helps, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGMKDR9CaO5/Lv0PARAkMBAJ9OqKjQn/K3TOxWaqaaD6qrNaBuPQCgqmOe WtTEmt56VxCMyzZ5g79FEBo= =G0w+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
