United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6932885 Java deployment cache size limit is not regarded
JDK-6932885 : Java deployment cache size limit is not regarded

Details
Type:
Bug
Submit Date:
2010-03-08
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2010-10-27
Component:
deploy
OS:
windows_vista,windows_xp
Sub-Component:
deployment_toolkit
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u18,6u20
Fixed Versions:
6u22-rev (b07)

Related Reports
Backport:
Backport:
Backport:
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

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 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.
                                     
2010-09-14
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
                                     
2010-10-15
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
                                     
2010-10-15



Hardware and Software, Engineered to Work Together