JDK-4166799 : URL-downloaded jar files (jar_cache files) never get deleted
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.2.0,1.2.1,1.2.2,1.3.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_nt
  • CPU: generic,x86
  • Submitted: 1998-08-17
  • Updated: 1999-05-20
  • Resolved: 1999-05-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 betaFixed
Related Reports
Duplicate :  
JDK-4215307 - Temporary files are left in the Windows TEMP directory
Duplicate :  
JDK-4222586 - java_cachexxx.tmp files are not deleted on close
Duplicate :  
JDK-4233380 - URLClassLoader does not delete cached jar files
Duplicate :  
JDK-4254020 - Plug-in 1.2.2 cache file remains on disk. And disk will full
Relates :  
JDK-4180369 - Cached URL-downloaded jar files are never, ever deleted
Relates :  
JDK-4167874 - URL-downloaded jar files can consume all available file descriptors
Relates :  
JDK-4406042 - File.deleteOnExit() doesn't work in java plug-in.
Description
The jar_cache temp files created by sun.net.www.protocol.jar.JarFileFactory never get deleted. As a result, you eventually run out of disk space, and deployed applications and services start failing.  This is a serious problem when using downloadable jar files for codebases in RMI.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic kestrel FIXED IN: kestrel-beta INTEGRATED IN: kestrel-beta
14-06-2004
SUGGESTED FIX It seems like the most desirable fix is to do a tmpFile.delete() in the finally clause in retrieve(), after you have an open fd to the file, so that the file will always get deleted even if the JVM later crashes or is killed. If for some reason that isn't safe, then use tmpFile.deleteOnExit().
11-06-2004
PUBLIC COMMENTS The jar_cache temp files created by sun.net.www.protocol.jar.JarFileFactory never get deleted. As a result, you eventually run out of disk space, and deployed applications and services start failing. This is a serious problem when using downloadable jar files for codebases in RMI.
10-06-2004
EVALUATION Using a fixed size hash table to cache the loaded jar files would solve the problem. A retirement policy can be used to retire entries in the cache when the cache becomes full. When a certain entry is retired, its corresponding temp file can be deleted. But this fix would be too complicated to put in at this stage, I am downgrading it to P4 for later possible considerations. The two suggested fixes will either not solve the problem correctly or totally. Deleting the temp file in the finally block is wrong, since the temp file is needed by the corresponding jar file if the jar file is to be cached. Using file.deleteOnExit will only delete the files when the JVM exits and will not solve the problem for long running applications. ###@###.### 1998-08-17 Respond to the new comments: If you call tmpfile.delete() while this tmpfile is being opened by a JarFile, on unix, the call would succeed while on win32 it will simply fail. So calling delete() in the finally clause will not solve the problem at all. ###@###.### 1998-08-25 This has been partly fixed in 1.2fcs by inserting an appropriate call to File.deleteOnExit. See 4180369. -- mr@eng 1998/10/9 For the record, the partial fix for 4180369 didn't work on win32 because of bug 4171239. jeff.nisewanger@Eng 1999-04-27 We have fixed this problem in Kestrel. The JarFileFactory will use special jar files which are deleted automatically once they are closed. This solves the problem on win32. ###@###.### 1999-05-25
25-05-1999