Hi,
Let say there is a webapp called mywebapp on a two member tomcat cluster.
Let's call the members tomcatA and tomcatB. The Developer wants to deploy a
new version of mywebapp. The following procedure was thought:
- Shut down one of the tomcats. Let it be tomcatA. From here on
the existing sessions will be served from tomcatB till further notice.
- Replace the clustered server.xml on tomcatA with a
non-clustered server.xml
- Bring up tomcatA. At this moment tomcatA is not participating
in the cluster, any session with the URL: http://hostA:8080/mywebapp should
have a standalone session id with no indication any of the two tomcat instances.
- Undeploy mywebapp.
- Deploy the new mywebapp on tomcatA with the olld name, that is
as mywebapp.
- Shut down tomcatA
- Replace the non-clustered server.xml with the clustered
server.xml
- Startup tomcatA
Here is the point where I need guidance.
- Does the tomcat cluster know that mywebapp on tomcatA is
different from mywebapp still running on tomcatB ? If yes, how does it know it
? Will at this point the sessions from tomcatB replicated to tomcatA ?
- If I want my new mywebabb to clusterized should I deploy it
also on tomcatB ? If yes - because somehow the cluster knows that although the
name and the context path is the same, the apps are in reality different -,
then how,t do so and at the same time preserve the existing sessions in
tomcatB, that is replicating them over to tomcatA.
My test shows, that if I just start up tomcatA with the new mywebapp on it as
soon as I shut down tomcatB the sessions over tomcatB are lost. I would like
to preserve those sessions and bring them over to tomcatA, so I can do the same
procedure on tomcatB that I did on tomcatA, that is replacing the old app with
the new one.
So I am interested how others are doing it without loosing any sessions and
without restrictions t the users.
Thanks ahead,
János
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
