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 :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
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