Webstart error: missing version response from server

Question

We deploy our application by Java Webstart. This works most of the time, but at the last update one client got an error when trying to update.
The jnlp-file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<!-- JNLP File -->
<jnlp spec="1.0+" codebase="http://xyz/webstart/app/" href="webstart.jnlp"> 
<information>   
  <title>xyz</title>   
  <vendor>xyz</vendor>   
  <homepage href="http://xyz"/>   
  <description>xyz</description>   
  <description kind="short">xyz</description>   
  <icon href="images/rvicon.gif"/>   
  <icon kind="splash" href="images/rvicon.gif"/>   
  <offline-allowed/> 
</information> 
<security>     
  <all-permissions/> 
</security> 
<resources>   
  <j2se version="1.5+"/>   
  <jar href="webstart.jar" version="0.52"/> 
</resources> 
<application-desc main-class="UseWebStartWithIsiplan"/>
</jnlp>The webstart__V0.52.jar is located in $CATALINA_HOME/webapps/webstart/app.
The user gets the following error:
Exception:
com.sun.deploy.net.FailedDownloadException: Ressource konnte nicht geladen werden: (http://xyz/webstart/app/webstart.jar, 0.52)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.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.prepareLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)Nested Exception:
java.io.IOException: missing version response from server
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
at com.sun.deploy.net.DownloadEngine.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.prepareLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)The client is running Windows XP SP2 and Java version 1.6.0_03-b05.
The Server is Apache Tomcat 5.5.23, Java version 1.5.0_12-b04.
Has anybody an idea what might cause this error?

Answer 1

We've gotten that error when the servlet runs out of memory. The out of memory error happens when it is building the jardiff file, which can require a lot of memory to do. The servlet caches any jardiffs that it builds, so most users won't see the problem because they are requesting prebuilt jardiffs.
We've found that the servlet runs best with 256mb of max heap. But I'd imagine we are more heavy weight users than most.
I've done some stress testing on the 1.5 servlet and did not find any real memory leaks.
Based on the open source version of the servlet (which I believe is pretty much the same as the one distributed with java 1.5).
It is keeping objects in memory to track which jardiffs it has built and to track any accessed resource (jar or jnlp). If your server has enough different jars and jnlps then you need to give it enough memory to keep all these small objects in memory.
If you want be 100% sure you've given it enough memory, then you can write a script which does a HEAD request on every possible jar and jnlp inside of the servlet. That should max out its memory usage.