https://issues.apache.org/bugzilla/show_bug.cgi?id=55821
--- Comment #3 from Colin Freas <cffil...@gmail.com> --- What I see in practice: in a development environment, I wind up with several jars in the autodeploy directory: myapp##1212.jar & myapp##1213.jar. Tomcat starts to deploy myapp##1212, eventually starts to deploy myapp##1213. If a lot of development & building has occurred, there may be many versions of the webapp in autodeploy. At this point, using autodeploy & parallel deployment together is not really tenable. I have to kill Tomcat, manually delete the jars & the exploded webapp directories, then restart Tomcat. Just to be clear, I have to do that during development because Tomcat isn't smart enough to deploy the latest version first. Yes, there may be these sessions written to disk, but what if there aren't? (Which case seems probable for the vast majority of developers during the vast majority of development.) Also, saying "let the background process undeploy the old versions once all the session[s] have exprired (which may be very soon after the restart...)" misses the point: undeploying the versions is often very quick, especially if there are no sessions. But how much of the combined deployment & undeployment time of each version is taken up by undeployment? My marginally complex webapp on a nice machine takes about 45s to deploy. If there are 4 or 5 versions, I should expect to wait 5 minutes for Tomcat to start? No: I'll invariably delete the old versions of the webapp as above. It seems like an improvement would be if Tomcat just did that for me or at least if there was a setting for Tomcat to do that for me. To me it just appears like the "undeployoldversions" feature was not adequately engineered or tested to account for the case of multiple webapp versions on Tomcat start (to say nothing of the situation in which the old versions fail to undeploy, which leaves something to be desired as well.) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
