Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8136906

Extreme Application Startup Time due to frequent requests for the jnlp-6.0.dtd

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b01
    • CPU:
      x86_64
    • OS:
      linux

      Backports

        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.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                herrick Andy Herrick (Inactive)
                Reporter:
                webbuggrp Webbug Group
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: