Mikolaj Rydzewski wrote:
Seth Ladd wrote:

The frequency is so much that the uptime of all of our applications is affected as we continually take down Tomcat servers in production to deploy a new application (or new version of the application). Because hot deploy does not work (the old favorite OOM error w/ too many redeploys), we bounce the Tomcat server for every redeploy.

What about clustering? You could move users to one node of the cluster, update apps in the second one, and then the opposite. Move users to the second node, update the first one and finally allow users to work with two (or more) nodes.

Yes, but then how to do you handle class evolution for objects in the session?

For example, if I'm clustering two Tomcats, they are sharing Session state. If I upgrade one node in the cluster, and possibly change a class definition of an object that gets stored in the session, I will now have two definitions of the same object (one for the old cluster node and one for the new cluster node). I think there will be serialVersionUID issues there.

Advice on how to handle that?


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to