https://issues.apache.org/bugzilla/show_bug.cgi?id=55821
--- Comment #4 from Mark Thomas <ma...@apache.org> --- (In reply to Colin Freas from comment #3) > 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. Parallel deployment isn't intended to be used in a development environment. > 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.) Then have your deployment process for the new version undeploy the old version(s) at the same time. > 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? Aside: You can use threaded deployment to reduce that to closer to 45s. > 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 undeployOldVersions (case matters) and the parallel deployment feature was designed for use in production environments were a seamless switchover to a new version was required. It wasn't designed to be used the way you are trying to use it. It isn't clear why you are trying to use parallel deployment in a development environment. There may be better solutions to the problem you are trying to solve but that would be a discussion for the users mailing list. > (to say nothing of the situation in which the old > versions fail to undeploy, which leaves something to be desired as well.) Failed undeployments are the responsibility of the code that has opened a file and failed to close it. I am not aware of any such bugs currently open against Tomcat. The most likely cause is a bug in the web app or a library it is using. These are often tricky to track down. To help, Tomcat 8 has introduced a feature for tracing locked files. You may find it useful to test your problematic apps with Tomcat 8 and the traceLockedFiles option (ask on the users list of you need help with this - it is still very new and currently undocumented). -- 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
