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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From [EMAIL PROTECTED] 2004-07-30 10:48 ------- As far as I can see each classloader also loads the "global" jars from Catalina, which would be the same for all web applications, so they are opened more than once and are not unique to the classloader. These could be shared easily with a global structure. Also leaving all jar's open all the time a web- app is running is still messy for servers with lot of webapps. And why did someone bother to close the jars after starting, if it wasn't necessary at some point ? You're right about closing all jars when stopping, I saw this, but still habe concerns about unreferenced jarfiles, because of the ioe catch outside the loop, may be this could be at least patched. Anyway we're testing now with a subclass of the classloader changing the openJARs method to avoid system limitations and it looks promising, so we'll follow that path instead of providing a patch (I wasn't really glad about this idea). We'll use an LRU with in-/decreasing upper limit, such that any IOE will increase the maximum amount of open jars with some lower notification limit. At least we don't have so many open file handles as before, and we will probably no longer see the original exception at this point. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
