Re: [PROPOSAL] Parallel deployment
Cool. Some notes ... (1) Since we already have - effectiveMajorVersion - effectiveMinorVersion Is Context.version a good name to use? Since the name version is also used by the servlet spec? Would revision be a less confusing name? (Or webappRevision). (2) [I thought of this as a side effect of reading the patch ...] Would it be a good idea if Tomcat by default always has a default ROOT webapp? Then we can guarantee a webapp is always mapped and we can let that webapp handle the 404 error. This might simplify some of the mapper and adapter code. So if there is no default webapp - tomcat inserts the default. -Tim On 10/21/2010 2:52 PM, Mark Thomas wrote: [A lot of stuff ... here is a link to it ...] http://markmail.org/message/h7fjzs52acykjkbj - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 22/10/2010 06:27, Tim Funk wrote: (1) Since we already have - effectiveMajorVersion - effectiveMinorVersion Is Context.version a good name to use? Since the name version is also used by the servlet spec? Would revision be a less confusing name? (Or webappRevision). Good point. Maybe webappVersion? (2) [I thought of this as a side effect of reading the patch ...] Would it be a good idea if Tomcat by default always has a default ROOT webapp? Then we can guarantee a webapp is always mapped and we can let that webapp handle the 404 error. This might simplify some of the mapper and adapter code. So if there is no default webapp - tomcat inserts the default. Another good point. Maybe just use the default servlet? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 22.10.2010 13:39, Mark Thomas wrote: On 22/10/2010 06:27, Tim Funk wrote: (1) Since we already have - effectiveMajorVersion - effectiveMinorVersion Is Context.version a good name to use? Since the name version is also used by the servlet spec? Would revision be a less confusing name? (Or webappRevision). Good point. Maybe webappVersion? Will it be a webapp provided version string, or some internal automatically provided version? If the latter, would it be more like a sequence? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 22/10/2010 06:55, Rainer Jung wrote: On 22.10.2010 13:39, Mark Thomas wrote: On 22/10/2010 06:27, Tim Funk wrote: (1) Since we already have - effectiveMajorVersion - effectiveMinorVersion Is Context.version a good name to use? Since the name version is also used by the servlet spec? Would revision be a less confusing name? (Or webappRevision). Good point. Maybe webappVersion? Will it be a webapp provided version string, or some internal automatically provided version? If the latter, would it be more like a sequence? I'm thinking normally user provided but there are some scenarios where Tomcat may determine the next version as a convenience. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
Hello, I was playing around with zero downtime releases since 2003 and I think there are some pitfalls in your approach I dont see yet solved. I'm taking as premise that you are targeting 'larger' sites, meaning loadbalancers, 4++ servers etc. Small sites don't really need this feature imho (the downtime costs are absolutely low). So, how do you want to handle following: 1. ressources - for the time you have both versions in parallel you'll have double resources need, double amount of db connections, double amount of memory etc. This means that the hosting has to sized accordingly, but hosting on 2times oversized machines just to save some seconds is very expensive. 2. time - the startup of the second instance will usually consume cpu resources. This can make the tomcat unresponsive. If the loadbalancer detects the unresponsiveness it will mark it as unavailable and switch all sessions anyway - nothing won. Usually you will have 30 seconds to perform the startup of the context. 3. end - a release needs an end. Having one user with open browser and continuos refresh shouldn't bind the resources forever. On the other hand, the same behavior is easily achieveable with a bit loadbalancer tuning and Vmware. Are you sure it is worth the effort? regards Leon On Thu, Oct 21, 2010 at 8:52 PM, Mark Thomas ma...@apache.org wrote: All, As most of you are probably aware I work for SpringSource and SpringSource has an application server product - tc Server - that is heavily based on Apache Tomcat. When talking to prospective clients about tc Server, one of the things we often hear is WebSphere/WebLogic has XYZ feature - does tc Server? and one of those features is parallel deployment. Parallel deployment is essentially having two (or more) versions of the same application deployed side-by-side. Users with a session in an older version, will continue to use that older version until the session expires. Users without a session, or whose session expires, will use the latest version. Once there are no sessions using the older version it is undeployed. All versions of the application have the same context path so the transition is seamless to the users. Having looked at some implementation options, it quickly became apparent that Tomcat was the right place to implement this rather than as an 'add-on' in tc Server. I have managed to convince senior management that contributing an implementation of parallel deployment to the ASF is the way to go. I currently have a hacked together implementation [1] that works but is very ugly in places under the covers and there is still some significant work to go before it is robust enough to be put into trunk (it changes the mapper and that is an area I think we need to be very careful). A lot of the patch is dealing with the issues around the fact that we currently treat Context.getPath() and Context.getName() as the same thing but with parallel deployment these need to be treated differently. My proposal is therefore: - start committing some of the getPath() / getName() clean-up to trunk along with some of the other hooks - like adding a version attribute to Context that should be minimal risk - continue testing the current patch (e.g. with clustering) and modify as required - discuss the implementation details (like the file naming convention used) on the dev list - decide once we can see the patch without the clean-up if it is safe for 7.0.x or needs to be held back for 7.1.x Depending on how big this patch ends up looking then creating a branch for this work may make sense. I'd like to hold off creating a branch for a few days until the clean-up changes have been made to trunk so the branch can focus on the diffs required for the new feature. As always, any and all feedback welcome. Mark [1] http://people.apache.org/~markt/patches/2010-10-21-parallel-deployment.patch - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
A bit of opinion from my side: On 22.10.2010 14:28, Leon Rosenberg wrote: 1. ressources - for the time you have both versions in parallel you'll have double resources need, double amount of db connections, double amount of memory etc. This means that the hosting has to sized accordingly, but hosting on 2times oversized machines just to save some seconds is very expensive. It would, but they wouldn't need to oversize w.r.t. CPU and it's also not really true for memory. Often lots of memory goes to sessions and there the premium for the second context would be more like 10%. DataSources can be shared even now between contexts, so should not be a problem between context versions. 2. time - the startup of the second instance will usually consume cpu resources. This can make the tomcat unresponsive. If the loadbalancer detects the unresponsiveness it will mark it as unavailable and switch all sessions anyway - nothing won. Usually you will have30 seconds to perform the startup of the context. I don't see a problem here. Startup is mostly single-threaded, hardware gets more and more concurrency. 3. end - a release needs an end. Having one user with open browser and continuos refresh shouldn't bind the resources forever. I think we don't say that this solves the update problem for all applications and environments. Using state over a long time obviously is a problem for switching webapps. So devs have to reconsider how they construct their apps. E.g. often the session is only used as a kind of cache, but the data could be reconstructed from the user identity. Short term I guess the multi version feature alone does already improve the situation for many users. And we should allow to forceably unload an old version, e.g. when administrators or scripts decide that it's no longer worth waiting for the few remaining sessions to eventually expire. Mid term, it would be nice if we could migrate a session. By this I don't mean copy all session attributes over classloader boundaries, but maybe something like copying simple things, like strings. Apps could probably detect this and reconstruct the more complex objects from the basic info. Just an idea. On the other hand, the same behavior is easily achieveable with a bit loadbalancer tuning and Vmware. Are you sure it is worth the effort? I do experience very different user companies out there. Some of them are very good in building scripted automatisms and now very well how to do more complex operations with their load balancers. Some of them do not and would prefer a more out of the box approach. I expect the target to sit between the very small deployments and the very big ones. It's the people that started small and need to grow because of their success, but still do not have a big IT department, who I think will like the approach. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 22/10/2010 13:28, Leon Rosenberg wrote: Hello, I was playing around with zero downtime releases since 2003 and I This isn't zero downtime. Tomcat already does that and has done for quite a while. This handles the case where sessions from version n can't migrate to version n+1 - e.g. to an incompatible change in the classes used for persisting data in the session. I'm taking as premise that you are targeting 'larger' sites, meaning loadbalancers, 4++ servers etc. Small sites don't really need this feature imho (the downtime costs are absolutely low). This is aimed at all sites - large and small. So, how do you want to handle following: 1. ressources - for the time you have both versions in parallel you'll have double resources need, double amount of db connections, double amount of memory etc. This means that the hosting has to sized accordingly, but hosting on 2times oversized machines just to save some seconds is very expensive. You'll only need double the resources if you have double the load. That won't be the case. The load will remain the same, just distributed across two web applications rather than a single one. There will be the increased permgen demands of an additional application deployed but that is usually a relatively small percentage of the overall memory requirements. 2. time - the startup of the second instance will usually consume cpu resources. This can make the tomcat unresponsive. I have never seen an app do that. Context initialization happens on a single thread so at the absolute worst, one thread will be consumed but that is only going to happen with an app that has a cpu intensive start-up. If the loadbalancer detects the unresponsiveness it will mark it as unavailable and switch all sessions anyway - nothing won. Usually you will have 30 seconds to perform the startup of the context. Context start-up can take as long as it likes. Requests won't get routed to the n+1 version of the context until it has started. 3. end - a release needs an end. Having one user with open browser and continuos refresh shouldn't bind the resources forever. So undeploy the old version of the app. That will force the switch. We could easily make that happen automatically after a configurable delay. On the other hand, the same behavior is easily achieveable with a bit loadbalancer tuning and Vmware. Not sure why VMware is a requirement. Yes, you can achieve the same aim with multiple instances and a load-balancer. However that requires much more plumbing than just deploying a WAR and won't work with the existing tool-sets for deployment (Ant, Maven, manager app, home grown etc.) without a fair amount of additional custom code to co-ordinate the multiple instances and the load-balancer config. Are you sure it is worth the effort? Yes. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On Fri, Oct 22, 2010 at 3:04 PM, Mark Thomas ma...@apache.org wrote: On 22/10/2010 13:28, Leon Rosenberg wrote: Hello, I was playing around with zero downtime releases since 2003 and I This isn't zero downtime. Tomcat already does that and has done for quite a while. This handles the case where sessions from version n can't migrate to version n+1 - e.g. to an incompatible change in the classes used for persisting data in the session. I'm taking as premise that you are targeting 'larger' sites, meaning loadbalancers, 4++ servers etc. Small sites don't really need this feature imho (the downtime costs are absolutely low). This is aimed at all sites - large and small. So, how do you want to handle following: 1. ressources - for the time you have both versions in parallel you'll have double resources need, double amount of db connections, double amount of memory etc. This means that the hosting has to sized accordingly, but hosting on 2times oversized machines just to save some seconds is very expensive. You'll only need double the resources if you have double the load. That won't be the case. The load will remain the same, just distributed across two web applications rather than a single one. There will be the increased permgen demands of an additional application deployed but that is usually a relatively small percentage of the overall memory requirements. Well the primary resource I see as a problem is heap. I have one customer who runs his tomcats with 12gb heap and another with 8. Both do that on 16 gb machines. They couldn't increase without resizing the machines. The heap is really used and not for session related content but for global caching etc. 2. time - the startup of the second instance will usually consume cpu resources. This can make the tomcat unresponsive. I have never seen an app do that. Context initialization happens on a single thread so at the absolute worst, one thread will be consumed but that is only going to happen with an app that has a cpu intensive start-up. If the loadbalancer detects the unresponsiveness it will mark it as unavailable and switch all sessions anyway - nothing won. Usually you will have 30 seconds to perform the startup of the context. Context start-up can take as long as it likes. Requests won't get routed to the n+1 version of the context until it has started. Ok, I have experience with some very heavy start applications - basically they produce 100% cpu load for 1-2 minutes, this can decrease the performance of other requests, but this is surely not a common rule for all applications. 3. end - a release needs an end. Having one user with open browser and continuos refresh shouldn't bind the resources forever. So undeploy the old version of the app. That will force the switch. We could easily make that happen automatically after a configurable delay. Sounds very well. On the other hand, the same behavior is easily achieveable with a bit loadbalancer tuning and Vmware. Not sure why VMware is a requirement. Yes, you can achieve the same aim with multiple instances and a load-balancer. However that requires much more plumbing than just deploying a WAR and won't work with the existing tool-sets for deployment (Ant, Maven, manager app, home grown etc.) without a fair amount of additional custom code to co-ordinate the multiple instances and the load-balancer config. I found many operations-manager to be extremely resistant against fancy-java-features and having a we-can-do-it-better-with-vi-attitude :-) This could be an experience related to my geographic location ;-) Are you sure it is worth the effort? Yes. :-) regards Leon - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 10/21/2010 08:52 PM, Mark Thomas wrote: - decide once we can see the patch without the clean-up if it is safe for 7.0.x or needs to be held back for 7.1.x If it doesn't break things or existing users configs, I have no problem of having it in 7.0. Adding 7.1 to the list would just confuse folks given that we even didn't have a stable 7.0 release yet. +1 on the initiative. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 10/22/2010 7:39 AM, Mark Thomas wrote: On 22/10/2010 06:27, Tim Funk wrote: (1) Since we already have - effectiveMajorVersion - effectiveMinorVersion Is Context.version a good name to use? Since the name version is also used by the servlet spec? Would revision be a less confusing name? (Or webappRevision). Good point. Maybe webappVersion? Sounds good. (2) [I thought of this as a side effect of reading the patch ...] Would it be a good idea if Tomcat by default always has a default ROOT webapp? Then we can guarantee a webapp is always mapped and we can let that webapp handle the 404 error. This might simplify some of the mapper and adapter code. So if there is no default webapp - tomcat inserts the default. Another good point. Maybe just use the default servlet? Maybe ... I was of thinking something like a webapp with this (logical) definition. Context path= docBase=/dev/null / And then (assuming) the default servlet is in $CATALINA_HOME/conf/web.xml we then will not need an extra web.xml (but it might be convenient to do so in case the defaults in the system web.xml have undesirable behaviors) -Tim - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 22/10/2010 14:15, Leon Rosenberg wrote: Well the primary resource I see as a problem is heap. I have one customer who runs his tomcats with 12gb heap and another with 8. Both do that on 16 gb machines. They couldn't increase without resizing the machines. The heap is really used and not for session related content but for global caching etc. Yep, that would be an issue if most of an app's heap usage was for cache. In that case multiple machines is probably a better option and one that gets better as you have more machines since you could roll the new version out across the machines one at a time. You'd need to be careful to time the upgrades so they roughly tracked the pace of users migrating between versions. You'd also need to be careful with clustering / load-balancing config but it is all do-able. Ok, I have experience with some very heavy start applications - basically they produce 100% cpu load for 1-2 minutes, this can decrease the performance of other requests, but this is surely not a common rule for all applications. Agreed, not a common case but one that can be handled with either approach. I found many operations-manager to be extremely resistant against fancy-java-features and having a we-can-do-it-better-with-vi-attitude :-) I certainly see a preference for being able to script as much as possible, rather than use GUI tools. This feature would be optional - no-one is going to be forced to use it. I was speaking at a conference this week and mentioned this at the end of my Tomcat 7 intro presentation when I was talking about future plans. General consensus in the room was that they liked the feature and would use it. That was a mix of developers and ops folks so I think there is a demand In the same way users aren't forced to do hot re-deployment but can do it if they want, parallel deployment will add another choice. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[PROPOSAL] Parallel deployment
All, As most of you are probably aware I work for SpringSource and SpringSource has an application server product - tc Server - that is heavily based on Apache Tomcat. When talking to prospective clients about tc Server, one of the things we often hear is WebSphere/WebLogic has XYZ feature - does tc Server? and one of those features is parallel deployment. Parallel deployment is essentially having two (or more) versions of the same application deployed side-by-side. Users with a session in an older version, will continue to use that older version until the session expires. Users without a session, or whose session expires, will use the latest version. Once there are no sessions using the older version it is undeployed. All versions of the application have the same context path so the transition is seamless to the users. Having looked at some implementation options, it quickly became apparent that Tomcat was the right place to implement this rather than as an 'add-on' in tc Server. I have managed to convince senior management that contributing an implementation of parallel deployment to the ASF is the way to go. I currently have a hacked together implementation [1] that works but is very ugly in places under the covers and there is still some significant work to go before it is robust enough to be put into trunk (it changes the mapper and that is an area I think we need to be very careful). A lot of the patch is dealing with the issues around the fact that we currently treat Context.getPath() and Context.getName() as the same thing but with parallel deployment these need to be treated differently. My proposal is therefore: - start committing some of the getPath() / getName() clean-up to trunk along with some of the other hooks - like adding a version attribute to Context that should be minimal risk - continue testing the current patch (e.g. with clustering) and modify as required - discuss the implementation details (like the file naming convention used) on the dev list - decide once we can see the patch without the clean-up if it is safe for 7.0.x or needs to be held back for 7.1.x Depending on how big this patch ends up looking then creating a branch for this work may make sense. I'd like to hold off creating a branch for a few days until the clean-up changes have been made to trunk so the branch can focus on the diffs required for the new feature. As always, any and all feedback welcome. Mark [1] http://people.apache.org/~markt/patches/2010-10-21-parallel-deployment.patch - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
I discovered this feature a while ago in Weblogic and I found this interesting. But as I always had classloader leaks, I had to restart the JVM anyway so that it defeated the purpose of the feature and I gave up dreaming of zero-downtime deployments. Now with tomcat memory leak protection features, this deployment option might be once again very interesting. 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 ? Sylvain On 21 oct. 2010, at 20:52, Mark Thomas wrote: All, As most of you are probably aware I work for SpringSource and SpringSource has an application server product - tc Server - that is heavily based on Apache Tomcat. When talking to prospective clients about tc Server, one of the things we often hear is WebSphere/WebLogic has XYZ feature - does tc Server? and one of those features is parallel deployment. Parallel deployment is essentially having two (or more) versions of the same application deployed side-by-side. Users with a session in an older version, will continue to use that older version until the session expires. Users without a session, or whose session expires, will use the latest version. Once there are no sessions using the older version it is undeployed. All versions of the application have the same context path so the transition is seamless to the users. Having looked at some implementation options, it quickly became apparent that Tomcat was the right place to implement this rather than as an 'add-on' in tc Server. I have managed to convince senior management that contributing an implementation of parallel deployment to the ASF is the way to go. I currently have a hacked together implementation [1] that works but is very ugly in places under the covers and there is still some significant work to go before it is robust enough to be put into trunk (it changes the mapper and that is an area I think we need to be very careful). A lot of the patch is dealing with the issues around the fact that we currently treat Context.getPath() and Context.getName() as the same thing but with parallel deployment these need to be treated differently. My proposal is therefore: - start committing some of the getPath() / getName() clean-up to trunk along with some of the other hooks - like adding a version attribute to Context that should be minimal risk - continue testing the current patch (e.g. with clustering) and modify as required - discuss the implementation details (like the file naming convention used) on the dev list - decide once we can see the patch without the clean-up if it is safe for 7.0.x or needs to be held back for 7.1.x Depending on how big this patch ends up looking then creating a branch for this work may make sense. I'd like to hold off creating a branch for a few days until the clean-up changes have been made to trunk so the branch can focus on the diffs required for the new feature. As always, any and all feedback welcome. Mark [1] http://people.apache.org/~markt/patches/2010-10-21-parallel-deployment.patch - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
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. 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 :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
On 21.10.2010 20:52, Mark Thomas wrote: All, As most of you are probably aware I work for SpringSource and SpringSource has an application server product - tc Server - that is heavily based on Apache Tomcat. When talking to prospective clients about tc Server, one of the things we often hear is WebSphere/WebLogic has XYZ feature - does tc Server? and one of those features is parallel deployment. Parallel deployment is essentially having two (or more) versions of the same application deployed side-by-side. Users with a session in an older version, will continue to use that older version until the session expires. Users without a session, or whose session expires, will use the latest version. Once there are no sessions using the older version it is undeployed. All versions of the application have the same context path so the transition is seamless to the users. Having looked at some implementation options, it quickly became apparent that Tomcat was the right place to implement this rather than as an 'add-on' in tc Server. I have managed to convince senior management that contributing an implementation of parallel deployment to the ASF is the way to go. I currently have a hacked together implementation [1] that works but is very ugly in places under the covers and there is still some significant work to go before it is robust enough to be put into trunk (it changes the mapper and that is an area I think we need to be very careful). A lot of the patch is dealing with the issues around the fact that we currently treat Context.getPath() and Context.getName() as the same thing but with parallel deployment these need to be treated differently. My proposal is therefore: - start committing some of the getPath() / getName() clean-up to trunk along with some of the other hooks - like adding a version attribute to Context that should be minimal risk - continue testing the current patch (e.g. with clustering) and modify as required - discuss the implementation details (like the file naming convention used) on the dev list - decide once we can see the patch without the clean-up if it is safe for 7.0.x or needs to be held back for 7.1.x Depending on how big this patch ends up looking then creating a branch for this work may make sense. I'd like to hold off creating a branch for a few days until the clean-up changes have been made to trunk so the branch can focus on the diffs required for the new feature. As always, any and all feedback welcome. Great initiative, good plan. Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Parallel deployment
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
