自 Java 1.7.0u40 以来 Java WebStart 应用程序的长时间启动延迟

Long startup delay for Java WebStart application since Java 1.7.0u40

提问by Michael B

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).

由于我们安装了 Java 1.7.0u45，我们的 WebStart 应用程序显示在 Windows 系统上启动时出现严重延迟（我们还没有尝试过其他平台）。

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.

症状是双击桌面上的应用程序图标后，启动画面很快出现，停留一段时间（就像以前一样）然后关闭。在此之后，我们有大约 1 分钟的延迟。然后，最后，应用程序窗口打开，一切都像魅力一样。

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

我们的应用程序在 Java 1.7.0u25 之前都没有问题。Java 1.7.0u40 是第一个出现问题的版本。

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.

我们的应用程序是从一个（可执行的）jar 文件构建的。最重要的部分是 jar 中的一些用于串行端口访问的本机类。我在这篇文章的末尾添加了 jnlp 文件。

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

我们试图找出延迟的原因：

Checked the Java WebStart release notesat http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.htmlfor our versions.

在http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html查看我们的版本的 Java WebStart 发行说明。

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.

在 Google 和 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.

有些人似乎有类似的问题，但我们从未见过解决方案。在许多情况下，人们在下载 jar 文件和重复下载时遇到问题。这似乎不是我们的问题。

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.

我们想知道应用程序在所说的一分钟内做了什么。所以我们使用了来自 sysinternals 和 wireshark 的进程浏览器和进程监视器。我们发现在等待时间内，进程试图通过 IP 与“vip1.g-anycast1.cachefly.net”（205.234.175.175）和 ​​93.184.220.29 进行通信。后者似乎是一个证书服务器，我不是很明白那个cachefly是什么东西。在这两种情况下，我们都看到了 TCP 同步，但没有应答，也没有进一步的通信。两个地址都可以ping通。

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 afterthe delay, not before.

与 IP 无关：我们确定，应用程序不是下载的，而是从缓存启动的，并且我们的 main 是在延迟之后而不是之前调用的。

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):

Jnlp（请注意，网址是手动修改的）：

<?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>

采纳答案by Michael B

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). Settingit 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.

是的，atulsm 的回答是正确的。但请继续阅读：我试图按照提示进行操作，但它看起来并不好，因为在 Java 控制面板中，该条目已被禁用（未设置勾号）。 设置它会导致标记仅临时显示（只要 WebStart 应用程序被执行并再次终止，设置就会返回到未选中状态），因此似乎该设置没有正确写入 Java 的配置文件。

FINALLY: I checked the Deployment Configuration Fileand set deployment.security.revocation.check=NO_CHECKmanually in the deployment properties. That did solve the problem!

最后：我检查了部署配置文件并deployment.security.revocation.check=NO_CHECK在部署属性中手动设置。那确实解决了问题！

回答by Atul Soman

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 !

我遇到过这个问题，这是因为默认情况下强制执行证书吊销检查。禁用它（高级选项卡 => 执行证书吊销检查），它应该没问题！

回答by Osama Lone

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

这发生在版本 1.8.0_221 以及 web start 应用程序中。我已经完成了，我发现的问题是每次下载 webstart 应用程序时都没有从缓存中加载。这是我在 deployment.properties 文件中所做的一些更改，我在其中添加了这两件事

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

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

您也可以从配置 java gui 工具更改这些设置在 jnlp 文件中，我更改了这两件事 1. 将更新检查设置从始终更改为背景 2. 分别从 128 和 256 增加了堆大小

<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.

第一个命令将 jnlp 导入系统缓存，第二个命令强制 jnlp 从系统缓存运行，而不是从应用程序运行或先下载它。

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

这大大减少了时间，但打开应用程序仍然需要 4 分钟。但在此之前，它需要超过 15 个，所以这是一个很大的改进。这是迈克尔 B 答案的延伸