JDK-6648395 : JWS can't find cache file after network crash
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6u4
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-01-08
  • Updated: 2010-09-03
  • Resolved: 2008-02-29
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 6 JDK 7
6u6 b01Fixed 7Fixed
Description
Customer reports an issue using Java WebStart 6.0u4 after a network crash.

1) Install software for the first time

Desktop icon points to

C:\WINDOWS\system32\javaws.exe "C:\Documents and
Settings\bioffe\Application
Data\Sun\Java\Deployment\cache\6.0\56\39a9fe38-259ec8ac"

The content of this directory is this
 Directory of C:\Documents and Settings\bioffe\Application
Data\Sun\Java\Deployment\cache\6.0\56

01/07/2008  05:20 PM    <DIR>          .
01/07/2008  05:20 PM    <DIR>          ..
01/07/2008  05:20 PM             2,956 39a9fe38-259ec8ac
01/07/2008  05:20 PM               361 39a9fe38-259ec8ac.idx
01/07/2008  05:20 PM               359 39a9fe38-6.0.lap

Everything works fine.

2)I update jnlp file and touch largest jar. It provokes massive
download, during which I simulate network outage, by pulling the 
plug or disable the network connection.
It rightfully fails. And I launch it again, with good internet
connection. Notice that information.

"C:\Documents and Settings\bioffe\Application
Data\Sun\Java\Deployment\cache\6.0\22\63c55516-2498876c"

 Directory of C:\Documents and Settings\bioffe\Application
Data\Sun\Java\Deployment\cache\6.0\22

01/07/2008  06:02 PM    <DIR>          .
01/07/2008  06:02 PM    <DIR>          ..
01/07/2008  06:02 PM             2,877 63c55516-391105fb
01/07/2008  06:02 PM               362 63c55516-391105fb.idx
01/07/2008  05:51 PM               359 63c55516-6.0.lap

The link points to nowhere.

We can no longer can execute this link. It fails with error.

CouldNotLoadArgumentException[ Could not load file/URL specified:
C:\Documents and Settings\bioffe\Application
Data\Sun\Java\Deployment\cache\6.0\22\63c55516-2498876c]
    at com.sun.javaws.Main.launchApp(Unknown Source)
    at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
    at com.sun.javaws.Main$1.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

In Java WebStart 5.0 this scenario is being handled gracefully.

This seems similar to bug 6446676, with the addition of a network crash in the middle of updating the jnlp file.

The customer's jnlp file and screenshots of the Java Console errors are attached.
Comments
SUGGESTED FIX The testcase did not work for me. I don't have write permissions to touch the files. $ ls -l total 89228 -rw-r--r-- 1 ngthomas staff 225984 Jan 16 15:15 draw.jar -rwxr--r-- 1 ngthomas staff 988 Jan 16 15:15 draw.jnlp~ -rwxr--r-- 1 ngthomas staff 1051 Jan 16 15:15 draw.jnlp -rw-r--r-- 1 ngthomas staff 799 Jan 16 15:15 index.html~ -rw-r--r-- 1 ngthomas staff 1272 Jan 16 15:19 index.html -rw-r--r-- 1 ngthomas staff 45403114 Jan 16 15:15 rt.jar
17-01-2008
SUGGESTED FIX Fix: Update existing shortcut right after cached jnlp is udpated. Testcase: http://web-east.east.sun.com/deployment/www/tests/1.6.0_10/6648395/ ================================ webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6648395.0
16-01-2008
EVALUATION I can reproduce the bug. Problem is caused by the sequence we update the cached jnlp file, resouces and shortcut. The cached jnlp file is the first we update, and remove the old cached jnlp file. Then we update each cached JAR as listed in the jnlp. And finally before we launch, we update the shortcut to point to the updated cached jnlp file. In this case, cached jnlp got updated in the beginning (created new jnlp and removed old cached one), and then the long JAR update begin. Here the networking crash happen, and java web start failed and exit. However, the shortcut are not updated to point to the new cached jnlp. So next time the user clicks on the shortcut again, it failed because it points to an non-existent jnlp file. If shortcut exists, we need to make sure once cached jnlp is updated, we need to make sure the shortcut points to the new jnlp in the cache too, even if the application did not get started.
15-01-2008