JDK-8074672 : Launching application via Java Web Start is much slower since 1.8.0_31
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u40
  • Priority: P3
  • Status: Resolved
  • Resolution: Cannot Reproduce
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2015-03-05
  • Updated: 2015-11-03
  • Resolved: 2015-11-03
Related Reports
Duplicate :  
JDK-8133095 - Signed jar files trust is always expired and always validated ->Slow app startup
Description
FULL PRODUCT VERSION :
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]

A DESCRIPTION OF THE PROBLEM :
We are launching our application via Java Web Start. We noticed that it takes much longer since update 8u31. It seems that the web start mechanism verifies the jnlp and each included jar for every start. The caching does not seem to work. Furthermore does the verification of our signature take a lot of time.

REGRESSION.  Last worked in version 8u25

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Start application via Java Web Start from "https://adam.lucanet.com/jnlp/jnlpfile/client/x_adam"

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Fast startup of the application.
ACTUAL -
Some starts of the application take up to 30 minutes.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Using an older version of Java than 8u31.

SUPPORT :
YES
Comments
Not able to reproduce the issue in the latest 8u60 build(b27). Issue seems to be solved by JDK-8079367.
03-11-2015
this is likely to be duplicate of JDK-8079367, please retest with 8u60.
24-09-2015
Added cached trace files for the versions 8u25, 8u40, 8u51. Attached file: 8074672.zip
06-08-2015
Console log is not enough. I couldn't reproduce it so please provide more information. Here is what you need to do to provide more: 1) run javaws -uninstall from the cmd line 2) goto c:\Users\<username>\AppData\LocalLow\Sun\Java\Deployment on Windows or ${HOME}/.java/deployment on Linux and edit deployment.properties. You need to add the following line there: deployment.trace.level=all 3) goto log subdir and remove all files from it 4) launch javaws https://adam.lucanet.com/jnlp/jnlpfile/client/x_adam It produces 2 *.trace files in the log dir. Rename them to something like clean1.trace and clean2.trace 5) launch javaws https://adam.lucanet.com/jnlp/jnlpfile/client/x_adam again. And rename 2 new trace files to say cached1.trace and cached2.trace. I need those trace files for 8u25 and 8u31 or 8u40 (the one that's slower) to analyze what's going on. So totally I need 8 trace files. This would provide much more information.
11-03-2015
Checked this for JDK 8u31 and 8u40 and following is the outcome. In the first instance, With JDK 8u31, it took around 5 minutes for the first time and subsequent start was quick (15 seconds). With JDK 8u40, it took around 10 minutes and subsequent start was slow, around 3 minutes. *********************************************************************** Note: With both JDK 8u31 and 8u40 the console (with cache entry) logged an java.net.ConnectException: Connection timed out: connect at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ********************************************************************** See attached console log for details.
09-03-2015