Error updating jar file
When I run my application on the client after deploying a new jar on the server, I get an error.
It looks like it loads the jar, verifies it, and then says it is unable to launch the application. Clicking on the "Details" button gives the exception listed below.
Trying to run the application a second time is successful (as it didn't have to copy the new jar file).
Any ideas?
Douglas Bullard
java.io.IOException: rename failed in cache
at com.sun.javaws.cache.DiskCache.insertEntry(Unknown Source)
at com.sun.javaws.cache.DiskCache.insertResource(Unknown Source)
at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload(Unknown Source)
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)
[1324 byte] By [
dbullard] at [2007-9-26 1:21:14]
Hi,
I have the same problem.
Check out thread:
http://forums.java.sun.com/thread.jsp?forum=38&thread=71597
You will probably find that the second time you access your application you get the old version starting up.
What seems to happen is that your java application fails to exit properly (possibly a JVM bug, as a System.exit(0) doesn't help) which leaves a lock on the local copy of the jar. If you subsequently release a newer jar on your web site, Webstart tries to download it, and fails when removing the local old one, as it is still locked. Second time through, the date-check on the jar is already up to date so it doesn't try to download it - which makes it appear to work second time through, but it reality you are just running the old code.
[The fact that the date-checking appears up to date even if a download fails seems to me to be a separate, very bad bug, as it leads to Webstart believing that its local code is up to date when in fact it is not.]
Killing the rogue javaw process or logging out fixes the problem, but it's not really an acceptable solution in a live environment !
Let's hope Sun come up with a fix soon.
Cheers,
John.
Hi,
Version-based downloading of jar files should fix this problem. In this case, you only download jardiffs from the server and patch the existing version of the jar file (even if it's locked, you have read access) to create a whole new file under a separate directory in the cache.
You may think about these issues before you decide to use the version-based system, though:
1. There is considerable setup work to do if you want to automate your release process.
2. It is not clear if you are saving much time by downloading jardiffs. JWS takes its time patching jardiffs and validating the new jar on the client side (has anybody else seen this?)
3. The client side cache keeps growing and growing.
Any comments and thoughts on version-based downloading will be appreciated.
