-
Bug
-
Resolution: Fixed
-
P2
-
6u14, 6u18
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2198785 | 7 | Hao Dong | P2 | Resolved | Fixed | b104 |
FULL PRODUCT VERSION :
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
EXTRA RELEVANT SYSTEM CONFIGURATION :
Also reproduced on Ubuntu Linux 9.04 Jaunty
A DESCRIPTION OF THE PROBLEM :
Webstart application installation works but JARs updated on the server are not downloaded (ignored completely).
My Webstart application's JNLP uses the following update settings:
<update check="always" policy="always"/>
This means that all resources should always be checked before the application starts and if a JAR is updated on the server (it has a newer timestamp), the JAR should be downloaded and placed in the cache.
Currently, in JRE 6u14, this seems to be completely broken. Webstart doesn't notice the updated JAR on the server and it doesn't download it.
As a check, I installed JRE 6u11 into an other Windows machine and tested the behaviour from the same Webstart web server.
JRE 6u11 works as expected. If I update the JAR on the web server and restart the application, Webstart immediately notices the new JAR and downloads it. This proves that there is no timestamp problem on the web server.
I checked the timestamps on the web server manually and they are correct. The webstart client and the server practically doesn't have any time difference (both are attached to internet time servers).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Any webstart application should be possible to use for reproduction:
- Make sure the JNLP has proper update settings (always)
- Install the webstart app, close it
- Update one of the JARs on the server, check that the timestamp is newer
- Start the previously installed webstart app
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Webstart should download the updated JAR
ACTUAL -
No download happens, Webstart starts the application with the OLD JAR
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
No workaround, practically makes Webstart unusable.
I have no idea how this bug made it to u14, there should be an automatic test case for this.
Please, fix this bug because all of the already installed Webstart applications are now frozen, it is impossible to update them on the client (if the user installs u14 but this can happen easily with JRE updates).
We have a lot of clients using our Webstart applications and some of them installed JRE 6u14 (a growing number).
Release Regression From : 6u11
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
java version "1.6.0_14"
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Client VM (build 14.0-b16, mixed mode, sharing)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]
EXTRA RELEVANT SYSTEM CONFIGURATION :
Also reproduced on Ubuntu Linux 9.04 Jaunty
A DESCRIPTION OF THE PROBLEM :
Webstart application installation works but JARs updated on the server are not downloaded (ignored completely).
My Webstart application's JNLP uses the following update settings:
<update check="always" policy="always"/>
This means that all resources should always be checked before the application starts and if a JAR is updated on the server (it has a newer timestamp), the JAR should be downloaded and placed in the cache.
Currently, in JRE 6u14, this seems to be completely broken. Webstart doesn't notice the updated JAR on the server and it doesn't download it.
As a check, I installed JRE 6u11 into an other Windows machine and tested the behaviour from the same Webstart web server.
JRE 6u11 works as expected. If I update the JAR on the web server and restart the application, Webstart immediately notices the new JAR and downloads it. This proves that there is no timestamp problem on the web server.
I checked the timestamps on the web server manually and they are correct. The webstart client and the server practically doesn't have any time difference (both are attached to internet time servers).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Any webstart application should be possible to use for reproduction:
- Make sure the JNLP has proper update settings (always)
- Install the webstart app, close it
- Update one of the JARs on the server, check that the timestamp is newer
- Start the previously installed webstart app
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Webstart should download the updated JAR
ACTUAL -
No download happens, Webstart starts the application with the OLD JAR
REPRODUCIBILITY :
This bug can be reproduced always.
CUSTOMER SUBMITTED WORKAROUND :
No workaround, practically makes Webstart unusable.
I have no idea how this bug made it to u14, there should be an automatic test case for this.
Please, fix this bug because all of the already installed Webstart applications are now frozen, it is impossible to update them on the client (if the user installs u14 but this can happen easily with JRE updates).
We have a lot of clients using our Webstart applications and some of them installed JRE 6u14 (a growing number).
Release Regression From : 6u11
The above release value was the last known release where this
bug was not reproducible. Since then there has been a regression.
- backported by
-
JDK-2198785 Webstart JAR updates are completely broken in 6u14
- Resolved
- duplicates
-
JDK-6890389 Race condition in parallel downloading of jars for applets and web-start
- Closed
-
JDK-6891798 2 tests from suite_javaws_certificates are failing from 6u18b03
- Closed
- relates to
-
JDK-6890258 6u18b03: 10% to 20% FX startup performance regression in javaws and plugins
- Closed