JDK-6800780 : Redundant fetches of jars causing severe startup time problems
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-02-03
  • Updated: 2013-10-17
  • Resolved: 2012-09-05
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 7 JDK 8
7u21Fixed 8 b55Fixed
Related Reports
Relates :  
JDK-6797730 - Umbrella: Applet startup performance improvements
Description
A JavaFX Lunar Lander app (see Comments section for its location) is causing the applicaation's jar file to be downloaded from the server over and over again. Attached is one thread dump showing that there are likely bugs in the CachedJarURLConnection or PluginURLJarFileCallBack classes where they are not properly hitting in the cache.

These cache misses occur every time a new JVM instance is started to run the app. When the app is run in the same JVM multiple times the issue does not occur. However, the most significant startup time problems are occurring during the first launch of JavaFX applets in a fresh JVM instance.
Comments
Verified with b111
17-10-2013
EVALUATION From emails from ###@###.###: > There is no "last-modified" header field in these responses - > it this case, it's an odd concept that is somewhat meaningless > and since the spec says "should" instead of "must", I leave the > header out. I suspect that the deployment code is erroneously > considering "missing" to be the same as "0". I do set > "cache-control". and > Given "cache-control: max-age=X", you're supposed to update the > cache X seconds after the file is fetched. From my read of the > specs, "cache-control" is the modern preferred mechanism, which > is why I use it. "last-modified" is somewhat frowned upon because > for synthetic content (which so much of the web is), it's rather > arbitrary and meaningless (that's why the spec says "should" > instead of "must"). and > If all of "last-modified", "expires" (the other deprecated header > in this domain) and "cache-control" are missing, you're supposed > to refetch immediately (at least, as I read the spec). I suspect > that a better performing behavior would be to assume > "cache-control: max-age=10", so that things stick in the cache > for about 10 seconds, blocking multiple immediate re-fetches. The deployment caching code should be updated to obey these new rules.
05-02-2009
EVALUATION There's some check in the deployment code to determine whether to cache a resource. A resource won't be cached if one of the following conditions is true: 1) the http "cache-control" header field equals "no-store" 2) both the http "last-modified" and the "expires" header field equal to 0 On the server where the testcase was staged, the "last-modified" header field is always set to 0. After staging the same testcase on a different server, the jar caching works fine. This seems to be a web server configuration issue.
04-02-2009