Created attachment 31513 [details] Profiling analyses Hi, If there are jar files in <app>/WEB-INF/lib, Tomcat keeps them opened and during undeploy they cannot be cleared. The following error appears: "SEVERE [ContainerBackgroundProcessor[StandardEngine[Catalina]]] org.apache.catalina.startup.ExpandWar.delete [...] could not be completely deleted. The presence of the remaining files may cause problems" The problem is because during startup of the application, a call to o.a.catalina.loader.WebappClassLoader.findResource is made, which opens the files. See the profiling analyses that are attached. (openedfiles.jpg) A possible solution would be to invoke java.net.URLClassLoader.close() in org.apache.catalina.loader.WebappClassLoader.stop method: Index: C:/tc8.0.x/java/org/apache/catalina/loader/WebappClassLoader.java =================================================================== --- C:/tc8.0.x/java/org/apache/catalina/loader/WebappClassLoader.java (revision 1585681) +++ C:/tc8.0.x/java/org/apache/catalina/loader/WebappClassLoader.java (working copy) @@ -1497,6 +1497,12 @@ permissionList.clear(); loaderPC.clear(); + + try { + super.close(); + } catch (IOException e) { + throw new LifecycleException(e); + } } What do you think? Regards Violeta
Steps to reproduce?
May not be directly relevant, but I've noticed that Java on Windows keeps an OS lock on files that it has got open - even when read-only. So one cannot delete jars that are in use (and it makes tailing log files tricky in Windows!) Unix Java does not seem to have this restriction.
> A possible solution would be to invoke java.net.URLClassLoader.close() in > org.apache.catalina.loader.WebappClassLoader.stop method: 1. What will be an effect of calling stop(),start() (I have not checked if anything calls those methods in a pair). If URLClassLoader cannot recover after a call to close() then it should be done in destroy() instead of stop(). 2. Are you running without a JreMemoryLeakPreventionListener ?
(In reply to Mark Thomas from comment #1) > Steps to reproduce? - ant clean deploy - go to output/build and start Tomcat - deploy the attached application - undeploy the application
Created attachment 31515 [details] example
(In reply to Konstantin Kolinko from comment #3) > 2. Are you running without a JreMemoryLeakPreventionListener ? It is there I did a regular "ant clean deploy" without any additional changes
Looking at this with YourKit the proposed patch (modified as suggested by Konstantin) addresses 2 out of the 4 open file issues I am seeing with lsof. I want to see if I can find the source of the remaining 2 files before I commit a fix. Note that triggering GC does clean up all the remaining open files.
I've committed a partial fix for this. I made some progress with tracking down the cause of the other files locks but still have some work to do there.
Fix in 8.0.x for 8.0.6 onwards.
We are seeing this issue as well in Tomcat 6.0.35 on Windows 7. Is there any chance of a back-port to Tomcat 6 or 7 for this fix?