DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30362>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30362 Tomcat eats up file handers Summary: Tomcat eats up file handers Product: Tomcat 5 Version: 5.0.27 Platform: All OS/Version: BeOS Status: NEW Severity: Blocker Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It seems to me that under some circumstances Tomcat don't release file handlers. I have the problem that after a while I got a lot of IOexceptions, because there are no more file handlers. Increasing the number of handlers with ulimit only shifts the problem in time, but is not a solution. I'm not really sure where it happens. I can see it in the log file: WebappClassLoader: Failed to open JAR java.util.zip.ZipException: Too many open files at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:112) at java.util.jar.JarFile.<init>(JarFile.java:127) at java.util.jar.JarFile.<init>(JarFile.java:92) at org.apache.catalina.loader.WebappClassLoader.openJARs (WebappClassLoader.java:1549) at org.apache.catalina.loader.WebappClassLoader.findResourceInternal (WebappClassLoader.java:1771) at org.apache.catalina.loader.WebappClassLoader.findClassInternal (WebappClassLoader.java:1575) at org.apache.catalina.loader.WebappClassLoader.findClass (WebappClassLoader.java:860) at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1307) at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1189) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302) [...] when I take a look at the WebappClassLoader.java everything seems to be okay, as far as I can see from the logic all file handles should be closed before new files are assigned. Anyway I could at some places imagine situations where an IOException won't close all file handlers. In such cases the openJAR method will overwrite existing jarFiles[] entries without closing them (try-catch outside loop). A simple solution would be to ensure integrity of jarFiles[] before changes (i.e. check whether the array entry is really closed and null), of course unreferenced file objects should be closed automatically somehow, but this seems not to happen (I got almost 1 GB log-file with this error during 2 days, so there is definetyl a leak). For installations with more deployments a global LRU-Cache with a fixed size upper limit of open filed would be probably more appropriate. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
