mboeckman> I have a problem that has occurred under mboeckman> tomcat-4.1.12/j2sdk1.4.1_02 that caused me to want to ask mboeckman> the group a question. The problem was "Too many open mboeckman> files", java.io.FileNotFoundException .
mboeckman> What I noticed is that Tomcat seems to keep a file handle mboeckman> to every .jar file in it's own CLASSPATH mboeckman> (/usr/local/tomcat-4.1.12/shared /commons /lib, etc) as mboeckman> well as in the unique hosts' classpath, per unique mboeckman> thread. So what I'm seeing is 5000+ file handles open to mboeckman> the same .jar files over and over again. mboeckman> Why are .jar file handles mboeckman> maintained in an open state indefinately, when mboeckman> classfiles/config files etc are not? jfarcand> You need to update to Tomcat 5 if you want that problem jfarcand> fixed. The required changes are too critical to apply them jfarcand> to the 4.1.x trunk. Wait a couple of days and try it with jfarcand> "soon to be release" 5.0.15, which is a stable Tomcat 5. Ouch. :( As a shorter-term workaround, you might try one or more of the following: - if open filehandles are not maintained for individual class files, try expanding your jars into each classloader's corresponding "classes" directory (i.e shared/lib/*.jar into shared/classes, etc). - try combining multiple jars into a single jar: make a temporary directory, unpack each jar into it, then jar up the temporary directory. Again, you'd need to do this on a per-classloader basis. If doing this, be careful of signed jars. You'll need to unsign them by removing any META-INF/*.SF, META-INF/*.RSA, and META-INF/MANIFEST.MF files. - try increasing the number of file descriptors at the os level. With a solaris machine, that's rlim_fd_cur and rlim_fd_max in /etc/system. I'm not sure about linux (/proc/sys/fs/file-max?) -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
