JDK-6964268 : Web Start Cache cleanup failed
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u20
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2010-06-25
  • Updated: 2011-02-16
  • Resolved: 2010-06-25
Related Reports
Duplicate :  
Description
FULL PRODUCT VERSION :
1.6.0_14-b08
1.6.0_20-b02

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
With Version 1.6 WebStart should be able to clean up the cache. If a maximum cache size (e.g. 512 MB) is configured the cache should not grow above this size.

When a WebStart application is always started directly (e.g. javaws http://server.domain.org/context/jnlp/start.jnlp) the cache is not cleaned up. In our current environment we have caches with a size of 3 GB and more.

When you start the WebStart Viewer application (javaws -viewer) the cleanup of the cache is performed. But this is not useful in an productive environment.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Configure a maximum size of e.g. 64 MB Cache size in the Java control panel.
Now start directly an WebStart application. After this perform an update of the application on the server an repeat the steps. After a while you can see that the cache grows above the given maximum.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Every time when a WebStart application is started the cache should be cleaned up if configured.
User must not start the WebStart Cache Viewer to clean up the cache.
ACTUAL -
The WebStart cache grows with no limit.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
I think the bug is placed in the class "com.sun.deploy.cache.CleanupThread" placed in the deploy.jar. The Sources can be found at java.net.

The CleanupThread is started and runs.
When the private Method "getCacheResourceFiles()" is called no cached entries are found.
The implementation read all subdirectorys from the Cache dir ("6.0"). This are the directories "0 - 63" - but the implementation does not look in theese subdirectorys where the resource entrys are placed.

So every time the cleanupThread is executed no resources can be found.