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 Wed, 28 Jul 2004 17:50:58 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





------- Additional Comments From sd@mediaclockwork.de  2004-07-28 17:50 -------
First, I think you can get an IOE here if you delete a jar-file which is 
referenced in the application, so the native close operation on the file 
handler may fail with an IOE.
But this is probably not our case, so still I'm not sure that the code of 
WebappClassloader is causing the problem of the file handler leak since this is 
an OS resource and shared by all classes using files, so it could also happen 
somewhere else.
In addition I still don't think it's a good idea to hold open references to all 
jar's here, because if you have a lot of applications with lots of jars to 
load, you might get to the OS limits. 
In "normal" cases this won't be a problem, but you might run against 
the "ulimit -n" limit, a more dynamic approach would be more failsafe (i.e. NOT 
set ulimit -n to maximum of your OS :-) ). 
You still have another array with filenames and pathes, so you can create file 
objects on demand. If you look at the constructor of ZipFile (and Jarfile 
inherits from there) there is an implicit native open(...) call, which might 
use one OS file handle (I don't know the implementation of this native method, 
so ???)
Ok, creating handles on demand might be more expensive, so to avoid this a 
static LRU Cache with a fixed (or even decreasable) size might solve problems 
here. 
If I'm totally wrong here (i.e. this could not happen, because some logic will 
prevent from problem), please tell me. 

Since then I'm still searching the leak...

---------------------------------------------------------------------
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