tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 30362] - Tomcat eats up file handers
Date Fri, 30 Jul 2004 10:49:00 GMT
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

sd@mediaclockwork.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME



------- Additional Comments From sd@mediaclockwork.de  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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message