JDK-8136906 : Extreme Application Startup Time due to frequent requests for the jnlp-6.0.dtd
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u60,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2015-09-09
  • Updated: 2016-04-26
  • Resolved: 2015-09-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u72 b01Fixed 9Fixed
Related Reports
Relates :  
JDK-8140264 - create junit test for JDK-8136906
Relates :  
JDK-8134919 - jvm startup is slow
Description
FULL PRODUCT VERSION :
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Linux pc-name 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux
Applies to other os (a mac os not known in detail and windows 8) too

EXTRA RELEVANT SYSTEM CONFIGURATION :
Do have a Server (Jboss 4 at the moment, increase in process), that provide .jnlp and .jar, runs fine;
say "use browser config" for network-settings in java control panel, very hight security settings, a well signed certificate which java seems to like, set an iceweasel as browser
Icewease uses "determine settings alone" in network config very well 
most important: the application works at all.

A DESCRIPTION OF THE PROBLEM :
We start that application.... and wait. Waiting is the main source of anger at the moment. When waiting a long time, the application will work finally.

Why do we have to wait? Well, every jnlp that is found tries to get the JNLP-6.0.dtd from sun.java.com, gets redirected to a valid oracle-source and all fine. But somehow this is done for every single jnlp. Twice: just right before he will go to his "get resource / verify resource" loading-window, and after this. 

This might not be a problem for small applications, but it is an issue for our application, which owns about 100 jnlp-files.

So every of these jnlp takes about one and a half second to get its dtd file, so we are at 150 seconds. And add another 150 seconds for the second run.

Older releases were able to start that application in about one minute. Now it takes about ten. But to be honest; I can't say if this is a bug or a security-feature. 
Why does it have to ask for every single jnlp... and why this was no problem back with 1.8.0_30?

REGRESSION.  Last worked in version 8u40

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)

Attention, one of us claims that it works as good using 1.8.0_45 from your archive, but coulnd't verify this properly. 

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Use a web launched programm of choise which owns a huge number of .jnlp that all contain the 6.0 as jnlp specs and bring some time and a coffee. 

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I hope the start will take that minute it did in 1.8.0_30
ACTUAL -
I can eat a whole pizza between launching the initial jnlp and seeing our program start its main class

ERROR MESSAGES/STACK TRACES THAT OCCUR :
no errors, sorry. 

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
use an older version of jre...
And we did place the JNLP-6.0.dtd at a local space and redirect the sun.java.com adress to this place. Now its even faster than with 1.8.0_30, but seriously... that can't be done at our customers environment in the way we can do it here in our basement... eh perfect working place.
Comments
to manually test run javaws apps from above http://oklahoma.us.oracle.com/www/tests/1.9.0/8136906/ and look at trace file or console to see that java.sun.com/dtd is not accessed. automated test is preferable, and will be provided as seperate cr: https://bugs.openjdk.java.net/browse/JDK-8140264
21-10-2015
Why there is no unit/regression test provided? Please either provide regression test or explain why it is not provided and add appropriate noreg-* label.
21-10-2015
URL: http://closedjdk.us.oracle.com/jdk8u/jdk8u/deploy/rev/44963b124d7a user: herrick date: Thu Sep 24 11:44:46 2015 -0400
29-09-2015
We can achieve this by setting the feature "http://apache.org/xml/features/nonvalidating/load-external-dtd" to false on the SAXParserFactory before creating the parser. We will no longer attempt to download the external DTD file when we are not validating.
23-09-2015
so next question why wasn't it cached ? and the answer is http://www.oracle.com/webfolder/technetwork/jsc/dtd/ is sending back cache control "no-store". caching seems to help some, but since original request is to java.sun.com and is redirected, we still make the first http request when it is cached. (second redirected one is skipped then) need to find way to not download the dtd (unless we want to implement user option to actually validate jnlp file)
22-09-2015
looks like we could just call SAXParserFactory.setValidating(false): spf.setSchema(null); spf.setValidating(false); SAXParser sp = spf.newSAXParser(); in com.sun.deploy.security.xml.XMLParser.parse(). but that is insufficient - parser is not validating, even by default, but it is still downloading the dtd file.
22-09-2015
OK - I added that header to a jnlp file for a simple app: http://oklahoma.us.oracle.com/www/tests/1.9.0/8136906/unsigned.jnlp <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE jnlp PUBLIC "-//Sun Microsystems , Inc//DTD JNLP Discriptor 6.0//EN" "http://java.sun.com/dtd/JNLP-6.0.dtd"> and with the new parser in 8u40 and JDK9, the dtd is downloaded: ------------------ javawsxxx.trace: ---------------- network: Cache entry not found [url: http://java.sun.com/dtd/JNLP-6.0.dtd, version: null] network: Connecting http://java.sun.com/dtd/JNLP-6.0.dtd with proxy=HTTP @ adc-proxy.oracle.com/10.231.234.37:80 network: CleanupThread used 35787 us network: Cache entry not found [url: http://www.oracle.com/webfolder/technetwork/jsc/dtd/JNLP-6.0.dtd, version: null] network: Connecting http://www.oracle.com/webfolder/technetwork/jsc/dtd/JNLP-6.0.dtd with proxy=HTTP @ adc-proxy.oracle.com/10.231.234.37:80 network: Connecting http://www.oracle.com/webfolder/technetwork/jsc/dtd/JNLP-6.0.dtd with cookie "ORASSO_AUTH_HINT=v1.0~20150514001632" ------------------------------------------------------- I was not aware that a standard SAX parser did that. However, changing to a 9.0 jnlp file (with entries not valid in jnlp 6.0 and missing entries that used to be mandatory: http://oklahoma.us.oracle.com/www/tests/1.9.0/8136906/unsigned2.jnlp I did not get any error, so am not sure if the jnlp file is even being validated by it's dtd. (If it is, reporting the error is turned off). so clearly the fix in 8u60 causing this customer the problem is https://bugs.openjdk.java.net/browse/JDK-8064476 not clear why the slowdown is so sever, possibly other jnlp files are using version 7.0 or 8.20 (who's dtd is not available on web) we need to look into anything we can do in parser code to create a parser that doesn't do the dtd validation.
22-09-2015
There is no specific test scenario yet, but submitter has provided more details about this issue. Moving this up for dev. team to consider.
22-09-2015
Sent an email to the submitter requesting more information: ======================================================= On 9/14/2015 1:00 PM, ....... wrote: > Hi Robert, > > Can you provide the program/url that could confirm this issue? If you could write back with the exact steps would be helpful as well. > > Thank You, >........ ==========================================================
16-09-2015