Message6601

Analysis:

In org.python.core.packagecache.CachedJarsPackageManager.addJarToPackages, jar files being indexed on first use are not explicitly closed. The patch attached corrects that (in one line).

Jython is creating an index for each jar in its classpath. The file descriptors become unreferenced, and will be garbage collected, but not soon enough to avoid FD exhaustion in some systems. An explicit close is required.

I have developed this on v2.5.1, the product reported at fault. However, the same code is in multiple versions and the 2.6 tip. I am using Windows 7 x64, which seems never to run out of fds.

Jython already has open (and keeps open) seemingly the same jar files as a side effect of initialisation: I assume with good reason. A superfluous jars on the classpath will strain resources, but at least now we only have one copy open.

Test:

I have not been able to make an automated test but I have observed the behaviour with Process Explorer on Windows 7 x64 and JDKs 1.5.0_22 and 1.6.0_26. The 1.6 JVM uses significantly fewer handles (around 240 peak) compared with the 1.5 (around 420) in the patched code.

Testing on a system that actually demonstrates fd exhaustion would seem a wise precaution but is not open to me.

I have run the regression test (ant clean regrtest) on the modified product with the same results for the patched code as on a clean v2.5.1 check-out. (That is 306 passes, 3 skipped, 2 fails, 2 unexpected.) The 2 failures are test_cmd_line (hangs, needs killing 3 times) and test_socket.

Action:

Would a project member rights to commit please take this up? This is my first contribution to Jython. If there is any other ceremony needed, or a different process, please let me know.