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>

Solution 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!

Solution 2

I have experienced this problem and it was because of the certificate revocation checks enforced by default. Disable that (advanced tab => Perform certificate revocation checks on") and it should be fine !

Solution 3

This occurred with the version 1.8.0_221 as well in the web start application. I have done it and the problem that i found was that each time the webstart application was being downloaded and wasn't loading from the cache. Here are a few changes that i made in the deployment.properties file I added these two thing in it

deployment.security.tls.revocation.check=NO_CHECK deployment.security.revocation.check=NO_CHECK
deployment.security.mixcode=DISABLE

You can change these settings from the configure java gui tool as well In the jnlp file i changed these two things 1. changed the update check setting to background from always 2. Increased the heap size from 128 and 256 respectively

<update check="background"/>
<j2se version="1.8+" initial-heap-size="256m" max-heap-size="512m"/>

Then i went to the command prompt and typed these

javaws -import -system -shortcut jnlp.jnlp
javaws -system -Xnosplash -wait jnlp.jnlp

The first command imports the jnlp into the system cache and the second one forces the jnlp to be run from the system cache rather that from the application one or by downloading it first.

To be safe run this command first to clear the non installed applications from the cache as well

javaws -clearcache

This has greatly minimized the time but it still takes 4 mins to open the application. But before that it was taking more than 15 so it's a big improvement. This is an extension to Micheal B's answer

Comments

[Blackvault]

Thanks that helped me as well.

[user643011]

My Web Start was stuck at "Verifying application". Retrying or even rebooting the whole computer did not help. However javaws -clearcache fixed the problem. Thanks for that hint!