United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4393792 Downloading new version of running app fails
JDK-4393792 : Downloading new version of running app fails

Details
Type:
Bug
Submit Date:
2000-11-30
Status:
Resolved
Updated Date:
2002-04-16
Project Name:
JDK
Resolved Date:
2002-01-17
Component:
deploy
OS:
windows_nt,generic,windows_98,windows_2000
Sub-Component:
webstart
CPU:
x86,generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
jaws-0.9-ea,jaws-1.0,1.0,1.0.1
Fixed Versions:
1.2.0 (1.2)

Related Reports
Backport:
Duplicate:
Duplicate:

Sub Tasks

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
WORK AROUND


Use the version-based download
rene.schmidt@eng 2000-11-30
                                     
2000-11-30
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
                                     
2001-03-09
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
1.2
hopper

FIXED IN:
1.2
hopper

INTEGRATED IN:
1.2
hopper


                                     
2004-08-31



Hardware and Software, Engineered to Work Together