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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
