JDK-6932885 : Java deployment cache size limit is not regarded
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u18,6u20
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2010-03-08
  • Updated: 2011-02-16
  • Resolved: 2010-10-27
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.
JDK 6 JDK 7
6u22-rev b07Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6964268 - Web Start Cache cleanup failed
Relates :  
JDK-6350698 - Java Cache Viewer shows incorrect resource sizes.
Relates :  
JDK-7011636 - Size of the cache is above the limit
Description
The property "deployment.cache.max.size" does not seem to be regarded
for Java Web Start applications.

The Java Deployment cache size was limited to 200MB in one experiment.
The Java Deployment cache grew to 223 MB by launching 17 Java Web Start 
applications one by one.
Comments
EVALUATION The fix implements the following cache size calculating rules: 1) Include files located in 0-63 cache subdirectories only 2) Exclude *.ico, *.lap, *-temp files 3) Some *.idx files may be orphaned (the corresponding resource file is missed), they are not included (rare case) 4) Some very recently downloaded resources may be not included Because of these rules: - there exists some difference between the actual size of the Java deployment cache directory content on the hard drive and the values shown by Java Cache Viewer (Cache.getCacheSize()) and used for controlling cache cleanup (CleanupThread.getCurrentCacheSize()); - the actual cache directory size on the hard drive may exceed the specified limit for some time but it reverts back to borders on the next opportunity. There are some minor points for further potential improvements: 1. Deletion of orphaned *.idx, *.lap, *.ico files 2. Deletion of orphaned *-temp files 3. Calculation of *.lap, *.ico file sizes 4. Fixing CacheEntry.getContentLength() usage in CacheEntry.removeBefore() and Cache.removeDuplicateEntries() methods
15-10-2010
SUGGESTED FIX Code review: http://jpsesvr.sfbay.sun.com:8080/ctetools/html/ViewDetail.jsp?index=3779 RTI: https://jetsvr.sfbay.sun.com:8443/BugApproval/ViewDetail.jsp?index=10186
15-10-2010
EVALUATION The problem is in com.sun.deploy.cache.CleanupThread. The function that enumerates all the cache resource files works incorrectly and *always* returns an empty list. This gives the total current cache size = 0 independently of what is actually inside the cache. com.sun.deploy.cache.CleanupThread.getCacheResourceFiles() looks for the resource files right in the non-system cache folder "C:\Documents and Settings\<username>\Application Data\ Sun\Java\Deployment\cache\6.0" but instead it should check its subfolders "C:\Documents and Settings\<username>\Application Data\ Sun\Java\Deployment\cache\6.0\[0..63]". These subfolders were introduced by CR 6387048: download engine and cache performance tuning in JDK 6 b77 and I guess it was forgotten to update CleanupThread. During my work on the fix I also found another issue. Both CleanupThread.removeResourceFromList() and Cache.getCacheSize() use CacheEntry.getContentLength() expecting that this method should return the length of the resource file. Actually, this method returns a value produced by URLConnection.getContentLength() or HttpResponse.getContentLength() (or by derived classes), and it rather comes from HTTP response header parameter value. Usually it differs from the actual file size. This difference is quite significant sometimes, and in some cases it even returns -1. This value shouldn't be used for cache size accounting, and we should use the actual size of the file on the storage instead.
14-09-2010