On 21.10.2010 23:11, Mark Thomas wrote:
On 21/10/2010 14:51, Sylvain Laurent wrote:
Though I can see how this can be done for a standalone tomcat instance, how do
you plan to do with clustered sessions ? Should the old version of the
application wait for all sessions in the cluster to expire ?
TBD. I haven't looked at this at all yet. There are lots of ways to
handle clean-up of older versions. My off-the-cuff idea is periodically
poll the manager and see how many sessions are still active. When that
hits 0, undelopy the app / stop the app / log a message / do nothing.
Possibly plus manager webapp feature "unload this version now".
Even in a cluster, every manager knows how many active sessions there
are across the cluster.
I haven't tested how this code behaves with a cluster yet. I plan to
play with that next week. My suspicion is that there will be a handful
of Context.getPath() vs. Context.getName() issues to fix and then it
will just work. We'll see :)
Yes, apart from code cleanup I also don't expect big problems. Possible
small races like node A expired the last session exactly when the user
hit another node B and the session message from B reaches A when the
context was unloaded. But similar types of races even exist today.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
