Long startup delay for Java WebStart application since Java 1.7.0u40

Question

Since we installed Java 1.7.0u45 our WebStart application shows a major delay on startup on Windows systems (we haven't tried other platforms).

Symptom is that after double clicking the application icon on the desktop the splash screen shows up quickly, stays for some time (as it did before) and closes. After this we have a delay of about 1 minute. Then, finally, the application window opens and everything works like a charm.

Our application worked without problems up to Java 1.7.0u25. Java 1.7.0u40 was the first version where the problem showed up.

Our app is constructed from a single (executable) jar file. The most exiting part are some native classes for serial port access that are inside the jar. I added the jnlp file at the end of this post.

We tried to find out what the cause of the delay could be:

Checked the Java WebStart release notes at http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html for our versions.

As far we can say, there's nothing that could cause the behaviour. We noticed that there are new Manifest entries (Permissions, Codebase, Application-Name). These were added.

Looked all over Google and stackoverflow.

Some seem to have a similar problem, but we never saw a solution. In many cases people have problems with downloading jar files and repeated downloading. This seems not to be our problem.

Used tough tools

We wanted to know what the app does in the said minute of time. So we used process explorer and process monitor from sysinternals and wireshark. We found out that in the waiting time the process tries to communicate via IP with 'vip1.g-anycast1.cachefly.net' (205.234.175.175) and 93.184.220.29. The latter seems to be a certificate server, I did not really understand what that cachefly thing is. In both cases we see a TCP syn, but no answer, no further communication. Both adddresses are pingable.

Not related to the IP-stuff: We're sure, that the Application is not downloaded, but started from the cache and that our main is called after the delay, not before.

This is where we are stuck

Any further ideas how to solve this? Are we the only ones experiencing this behaviour?

Jnlp (Note that the urls are manually reworked):

<?xml version="1.0" encoding="UTF-8"?>
<jnlp  spec="6.0+" codebase="http://53.48.16.33:8180/jenkins/job/TcuTerm%20-%20Deploy/lastSuccessfulBuild/artifact/5000_Construction/5100_Code_Base/TcuTerm/antlocal" >
    <information>
      <title>TcuTerm</title>
      <vendor>Development</vendor>
      <icon                 href="http://53.48.16.33:8180/jenkins/job/TcuTerm%20-%20Deploy/lastSuccessfulBuild/artifact/5000_Construction/5100_Code_Base/TcuTerm/src/com/x/tcu/app/term/resources/tcu.jpg"/>
      <icon kind="shortcut" href="http://53.48.16.33:8180/jenkins/job/TcuTerm%20-%20Deploy/lastSuccessfulBuild/artifact/5000_Construction/5100_Code_Base/TcuTerm/src/com/x/tcu/app/term/resources/tcu.jpg"/>
      <icon kind="splash"   href="http://53.48.16.33:8180/jenkins/job/TcuTerm%20-%20Deploy/lastSuccessfulBuild/artifact/5000_Construction/5100_Code_Base/TcuTerm/src/com/x/tcu/app/term/resources/splash.jpg"/>
      <homepage href="https://confluence.detss.corpintra.net/display/TCU/TcuTerm"/>
      <offline-allowed/>
      <shortcut>
        <desktop/>
        <menu submenu="TcuTerm"/>
      </shortcut>
    </information>
    <security>
      <all-permissions/>
    </security>
    <resources>
      <j2se version="1.6+" href="http://java.sun.com/products/autodl/j2se"/>
      <jar href="TcuTerm.jar" main="true"/>
    </resources>
    <application-desc main-class="com.x.tcu.app.term.TcuTerminal"/>
    <update check="timeout"/>
 </jnlp>

Answer 1

Yes, atulsm's answer gave the right kick. But read on: I tried to follow the hint, but it did not look good since in the Java Control Panel the entry already was disabled (the tick was not set). Setting it resulted in the tickmark being only shown temporarily (as soon as a the WebStart application was executed and terminated again, the setting went back to not selected), so it seems as if the setting is not properly written into Java's config file.

FINALLY: I checked the Deployment Configuration File and set deployment.security.revocation.check=NO_CHECK manually in the deployment properties. That did solve the problem!