-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
7u21
-
windows_7
FULL PRODUCT VERSION :
java version " 1.7.0_21 "
Java(TM) SE Runtime Environment (build 1.7.0_21-b12)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Any version of Windows. Windows 7 (32/64-bit) and WIndows 2003+, etc.
A DESCRIPTION OF THE PROBLEM :
This issue is experienced on JRuby (+ Warbler).
Warbler extracts JARs to a Windows temp folder, with each JAR file having deleteOnExit() called.
It then adds the path of each JAR to a URLClassLoader and supplies it to JRuby, which JRuby then uses as the parent URLClassLoader to the many JRubyClassLoader objects it initializes internally.
At exit, `close()` is called on the parent URLClassLoader which allows for some of the temporary JAR files to be deleted at exit. However, the descendent JRubyClassLoaders seem to be keeping the file handle open and Java cannot delete the temporary JARs on exit.
Eventually these temp JARs will consume all available hard drive space, as the Windows temp folder is persistent across restarts.
Ideally descendent URLClassLoaders would respect the parent's close() call. Or Java would internally ensure that their file handles are closed prior to triggering the deleteOnExit event.
REGRESSION. Last worked in version 7u21
REPRODUCIBILITY :
This bug can be reproduced always.
java version " 1.7.0_21 "
Java(TM) SE Runtime Environment (build 1.7.0_21-b12)
Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Any version of Windows. Windows 7 (32/64-bit) and WIndows 2003+, etc.
A DESCRIPTION OF THE PROBLEM :
This issue is experienced on JRuby (+ Warbler).
Warbler extracts JARs to a Windows temp folder, with each JAR file having deleteOnExit() called.
It then adds the path of each JAR to a URLClassLoader and supplies it to JRuby, which JRuby then uses as the parent URLClassLoader to the many JRubyClassLoader objects it initializes internally.
At exit, `close()` is called on the parent URLClassLoader which allows for some of the temporary JAR files to be deleted at exit. However, the descendent JRubyClassLoaders seem to be keeping the file handle open and Java cannot delete the temporary JARs on exit.
Eventually these temp JARs will consume all available hard drive space, as the Windows temp folder is persistent across restarts.
Ideally descendent URLClassLoaders would respect the parent's close() call. Or Java would internally ensure that their file handles are closed prior to triggering the deleteOnExit event.
REGRESSION. Last worked in version 7u21
REPRODUCIBILITY :
This bug can be reproduced always.