JDK-4393792 : Downloading new version of running app fails
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: jaws-0.9-ea,jaws-1.0,1.0,1.0.1
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,windows_98,windows_nt,windows_2000 generic,windows_98,windows_nt,windows_2000
  • CPU: generic,x86
  • Submitted: 2000-11-30
  • Updated: 2002-04-16
  • Resolved: 2002-01-17
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.
Other Other
1.2.0 1.2Fixed 1.4.1Fixed
Related Reports
Duplicate :  
JDK-4391903 - The javaws hangs on Windows client.
Duplicate :  
JDK-4375349 - DownloadService does not remove on windows
Description
from customers feedback: ( ###@###.###)
> 2. If my app is already running when Java Web Start tries to download a 
> newer version, the newer version gets "lost". Specifically, this happens
> when there is a new version of the app available. The first time I click on
> the JNLP link, it tells me that Java Web Start will download the new version
> the next time. If I click on this link again before closing the first one,
> it downloads the new app, but won't start it. If I then close the app and
> click on it again, Java Web Start thinks it has the latest version, but
> actually runs the older version. Much of this could be avoided if you
> implemented the change I suggested earlier to give the user the option to
> download the new version immediately rather than waiting for the next time.
> 

If we try to write to a file that is open, the write will fail.
We should verify that the applications files are writable before atempting to 
download a new version.




Name: nt126004			Date: 11/06/2001


java version "1.3.1-rc1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-rc1-b21)
Java HotSpot(TM) Client VM (build 1.3.1-rc1-b21, mixed mode)


I have realized that when an application update is available and you have the
same application runnig, updating fails.
JavaWebStart trys to overwrite the jar files but the OS doesn't allow this
operation because the file is in usage.
However the next time you click on the jnlp link JavaWebStart doesn't detect
the new version. I think JWS has yet written the new version control on the
client although it hasn't been update correctly.

To reproduce:
1. Start an application via a jnlp link.
2. Update the jar file.
3. Start the application again via the link (original instance still running).
4. You get the exception:
JNLPException[category: Download Error : Exception: java.io.IOException: rename 
failed in cache : LaunchDesc: null ]
        at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
        at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
        at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
        at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
        at com.sun.javaws.Launcher.downloadResources(Unknown Source)
        at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
        at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
        at com.sun.javaws.Launcher.run(Unknown Source)
        at java.lang.Thread.run(Unknown Source)
5. Quit the application and start it again from the link.   No download is performed, but
you get the old version!
(Review ID: 135107)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.2 hopper FIXED IN: 1.2 hopper INTEGRATED IN: 1.2 hopper
31-08-2004
EVALUATION I have been investigating bug #4393792: Downloading new version of running app fails, and I have come to the conculsion that it is just not true. 1.) All of the paths thru DiskCache.java, except for deleteEntry throw up an IOException (which is later wrapped as a JNLPException) if the operation is not a success. In particular, insertEntry() which does the actual rename of the temp file to the correct cache file name, explicitly throws such an exception if the rename fails. 2.) I ran a simple test on NT (renaming t1.jar and t2.jar to T.jar and running both) which clearly shows jar files are not left open simply because they are "running" (java opens, reads, and closes them as expected). This may not be the case for native library dlls in jar files, but certainly is for classes. 3.) If any SecurityException, JNLPException, or IOException is thrown whil downloading or installing, LaunchErrorDialog.show() will be called. this does a System.exit(-1) so we could never get to the code that Resets force update, and, as the description of this bug says: "If I then close the app and click on it again, Java Web Start thinks it has the latest version, but actually runs the older version." andy.herrick@East 2001-03-04 Since noone has yet been able to provide example of how to reproduce, I am downgrading this to P4 - if example is provided will upgrade and escallate. andy.herrick@East 2001-03-09 New cache reorg in 1.2 should allow you to dowwnload running app. andy.herrick@East 2001-07-13
09-03-2001
WORK AROUND Use the version-based download rene.schmidt@eng 2000-11-30
30-11-2000