JDK-6672788 : REGRESSION: javawebstart can not handle high latency network
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u4,6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-03-07
  • Updated: 2010-09-17
  • Resolved: 2008-04-15
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.
6u10 b22Fixed 7Fixed
Related Reports
Duplicate :  
J2SE Version (please include all output from java -version flag):
 java version "1.6.0_10-ea"
 Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b12)
 Java HotSpot(TM) Client VM (build 11.0-b11, mixed mode, sharing)

Does this problem occur on J2SE 1.4.x or 5.0.x ?  Yes / No (pick one)

Operating System Configuration Information (be specific):
  Windows XP PRO SP2
  IE 7.0

Hardware Configuration Information (be specific):
  Sony VAIO laptop 2.8 Gz
  1.25 GB RAM

Bug Description:
Tested consumer JRE version of webstart and there are still big problems with
webstart.  The downloads are still done incorrectly.

You will notice the critical race condition here that breaks on of the fundamental requirements of webstart...launching an application.  

As it is currently, unpredictable java Errors can occur at runtime (like NoSuchMethodErrors) which should never happen.  When got these Errors, it is because
webstart is running applications with different incompatible libraries.  The 
libaries on the server are always compatible, but the downloading of them is 
not consistent and therefore old and new libraries are mixed....sometimes with 
terrible results.

Restarting the application will cause the webstart cache to re-sync itself 
(thank goodness for this), and the problem *invariably* goes away.  To restate 
this:  The first time the application is started after a a library update often
does not work.  The second time *always* works.

What seems to happen is this:
* Transactions are created to check the timestamps on the cached files.
* If this is not fast enough, the application will start anyway...leaving the 
downloads to occur after the application has started.

This would fully explain bug 6632928 in which the certificate dialog comes up 30
times...and it is ok to cancel almost all of them.  It comes up for each time it 
is trying to test/downloaded a jar file.  The application should be waiting for this
process to complete.  However, since the application starts anyway, it can try to 
run off of the older libraries that exist in the cache.

----Important design note ---------
When using certificate authentication, starting a thread to simulatiously check each 
cache entry is undesireable since, if the process requires user intervention, they 
will get prompted many times.  (User intervention could be necessary because of 
multiple certificates, or because the certificate is on a device that requires

Steps to Reproduce (be specific):

In your download servlet; in the JNLPDownloadServlet, change the sendRespond method 
of DownloadResponse.java to sleep for 5 seconds before it starts to transfer to data.
This will simulate a high latency network.  Also, make sure your test case has several 
jar files.  (I am not using versioned jar files and all the jar-diff stuff.)

Now, download and run the app.  If this is the first time, everything will work fine,
although because of the 5 second sleep, things will take a long time to download.

Now exit the app and then touch all your jar files (by touch, I mean the unix 'touch' 
to update the timestamps)

Launch the application again.  It will come up immediately, which should not be the 
case since it should be downloading the new jar files

Now, however, even with the application started, webstart will continue to download 
the jar files.  Checking the timestamps of the webstart cache entries validates the
assertion that jar files are being updated after the application has started. 

**Repeat: Even after my application has started, cache entries are being updated!**  

Remember that the application has started.  In this test we just touched the files, 
but in production, these jar files might be quite different than the ones there are
replacing.  If methods are ever changed or removed, this will cause runtime Java Errors
that should never happen.

The download also seems to cause the application to suspend for a while.  I don't know 
if the downloads freeze the class loader for a while or something.  My application 
will just freeze for a few minutes (persumably during the downloading) and then 
continue where it left off.  Duing this time the user has no idea what is happening.

WORK AROUND <update check="always" /> add this to force java web start 6 to always perform all the update check before the application starts

EVALUATION i can reproduce the problem. i used a modified JNLPDownloadServlet as suggested by the original bug submitter. the problem should only occur to resources marked lazy in the jnlp file though. in java 6 implementation of the download engine, by default the update check is set to timeout. so if after 1.5s we cannot perform update check on all the resources, we will continue to do the check in background, and start the application using cached resources. if the update check found a update for a lazy resource, it will actually remove the resource from the cache, and this is causing problems. for example, the application has 3 jars, a b c, a being the entry point main-class. c is a lazy resource. first launch, eveyrthing is cached. now webserver updated a and c. second launch, due to network problems, update check did not finish and continue in background, so a gets loaded to start the application. so now while a is loaded and running, update check continue and found c is updated. c, being a lazy resource, is removeed right the way. and now a tries to load c, since the old cached c is removed, it download the new c and cache it. but a is calling old lib in previous c -> java.lang.NoSuchMethodError.