Webstart cache bug? ClassnotfoundExeption BUT IS IS THERE!

Question

Hi,
we have a swing application that is launched via webstart.
This worked fine over years with all versions of java 1.4 up to 1.5, but with 1.6 from time to time we are facing a strange problem:
-From time to time, rarely, the application cannot be launched via webstart, it returns with a class-not-found-exception. Neither the jnlp., nor the jars or anything else has changed!!!
-I know, the Expiry attributes in the HTTP header have to be set correctly, and i verified also that the http communication is correct(by monitoring the network).
-This happens only if the application is in the Java webstart cache. If the problem occurs and i clean the cache, the problem is solved.
-However, if the problem occurs, the files are inside the javaws cache and the class that is not being found by Webstart is definetly there!!!
-You can easily tell if JavaWS attempts to download a resource or not, but in the error case it looks like it accesses ONLY the cache , but it fails to read from it.
-We think that, from time to time, Java WS fails reading the jar out of the cache, since in 75% of all error cases its the Main-Class that is not being found (but it is there in the cache). The fact that the remaining 25% other classes are not found show that the problems does not come from my main class.
-This happens for a lot of users (as i said rarely, but it happens). Its not ideal to tell a end-user to flush the webstart-cache, so has anybody experienced similar problems or knows whats going wrong here?
many thanks...

Answer 1

I analyzed the cache of webstart and i found out the following:
Unlike as in 1.5, in the new 1.6 Version Webstart places jar files under a cryptic name in the cache. When viewing the cache by the java control panel, you'll see your jar-file with a size in KB, lets say 4500. When looking in the cache, the 4500 are divided into the jar-file (the actually 4000KB on the server) and and .idx-file (the remaining 500KB).
1.) Today, i launched the ws application for the first time after a long period on the testing pc. This caused WS to create a new subfolder under its own caching-folder, where it has stored a .idx-file and a .lap file and a file with no file-extension.
content of .idx: the URL of the jnlp that i loaded (nothing else)
content of .lap: the date+time from last access today, the number of launches of the application for today, the entry "forcedUpdateCheck=true", and the parameter "lastAccessed" with the date+time for today as value.
content of file with no file-extension: the jnlp file itself
->the jar file is missing. As far as i understand, this is no error, it can be in any subfolder in the caching-directory.
2.)I found the according .jar-file in the cache in another subfolder. By analyzing the content of this folder, you can tell that this is the folder created at the last time i launched the WS application some days ago (it contains .idx etc with date information) .
The jar file is correct and by renaming it to .zip you can easily see that the missing class IS DEFINETELY THERE!!!
3.)in the old cache-subfolder from the last launch some days ago, the .idx-file shows some HTTP-information, also the header: it gives an "expiry" for the http-call for the jnlp file for today, at the first time i accessed the jnlp (the very first launch today).
Conclusion:
Under strange conditions and if the resource expires, it is possible that JavaWs is not able to update the cache. This results in the fact that classes cannot be found because the jar-file cannot be read, due to:
a)missing mapping of new entry to old value in another folder
b)concurrent modification
Possible reasons:
-concurrent modification of the folders is causing trouble to the cache management logic, results in loosing the abillity to map the cache entry to the according value in another subfolder in the cache. I think the naming of files in the cache has been changed from 1.5 to 1.6, so perhaps there is a still a bug. If the cache is cleared by the java control panel, the problem is gone.
Last but not least:
Some of my collegues had the idea that the problem is also related to mutlipe launches of Webstart or any Java-Application, wich might cause problems in terms of concurrencies of java processes. The interesting thing is, that the moment i launched the same application under my ide (eclipse) as an application via giving the main-method as startpoint (means non-Webstart-mode), and during the launch i started the same application as a webstart-application from a browser, the problem occured. Not to say that launching applications from my ide has something to do with webstart (god,hopefully not), but it is strange that exactly at this moment the problem occured....but: also end-users with no ide's that launch over webstart see the problem. btw: the launch of webstart failed, but the concurrent launch via eclipse was successful.