United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: 6648395 JWS can't find cache file after network crash
6648395 : JWS can't find cache file after network crash

Details
Type:
Bug
Submit Date:
2008-01-08
Status:
Resolved
Updated Date:
2010-09-03
Project Name:
JDK
Resolved Date:
2008-02-29
Component:
deploy
OS:
windows_xp
Sub-Component:
webstart
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u4
Fixed Versions:
6u6

Related Reports
Backport:
JDK-2198227 - JWS can't find cache file after network crash

Sub Tasks

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
2008-01-17 
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
2008-01-16 
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.
2008-01-15


Hardware and Software, Engineered to Work Together