JDK-6189594 : Java Webstart application startup is too slow
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.3.1
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-11-02
  • Updated: 2010-12-07
  • Resolved: 2005-01-19
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 JDK 6
1.4.2_08Fixed 6 b20Fixed
Description
Java Webstart uses a disk cache to keep local copies of referred resources of JNLP-files. 
JNLP Specification offers version-based download of resources, which allows simple way to specify current version of resources and also allows differential updates (JarDiff).
If the number of referred resources increases and/or disk cache contains many version sub-directories Java Webstart starting process gets very slow, even if no update of the referred resources is available.
The poor startup performance is based solely on disk cache lookup and is not related to any slow http or ftp downloads.
###@###.### 11/2/04 18:49 GMT
Comments
SUGGESTED FIX Suggested fix is basically a combination of optimized lookups and a trade of memory for speed. I created a prototype based on Java Webstart source 1.0.1_05 with following changes: fast lookup of a given versioned resource file In memory caching of created internal structures (DiskCacheEntry) In memory caching of created disk cache resource filenames ###@###.### 11/2/04 18:49 GMT I've added the Frank's prototype to the attachments ###@###.### 2004-11-26 09:18:16 GMT
02-11-2004
EVALUATION performance problem is mainly due to using hundreds of different versions, and the policy in DiskCache.java of 1.) storing versioned resources under a directory named for the version. 2.) accessing all versions of a resource before deciding which is best to satisfy a version string specification, and 3.) accessing the entire Cache Object of each resource, instead of just it's version string. As a result of this, for each request to check for the existance of a version of a resource, all version directorys must be checked. I have created a local test program to illustrate the problem: http://oklahoma.east/jnlp-servlet/deployment/javaws/stress/stress.html The redesign of the cache in Mustang will address this problem, but we should also address it in the curent cache design, so it can be backported to earlier releases. ###@###.### 2004-12-06 19:08:02 GMT
02-11-2004