United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6189594 : Java Webstart application startup is too slow

Details
Type:
Bug
Submit Date:
2004-11-02
Status:
Resolved
Updated Date:
2010-12-07
Project Name:
JDK
Resolved Date:
2005-01-19
Component:
deploy
OS:
windows_2000
Sub-Component:
webstart
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
1.3.1
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

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
                                     
2004-11-02
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
                                     
2004-11-02



Hardware and Software, Engineered to Work Together