自Java 1.7.0u40以来Java WebStart应用程序的启动延迟很长 [英] Long startup delay for Java WebStart application since Java 1.7.0u40
问题描述
由于我们安装了Java 1.7.0u45，因此我们的WebStart应用程序显示Windows系统启动时出现重大延迟（我们还没有尝试过其他平台）。
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).
症状是那样的双击桌面上的应用程序图标后，启动画面会快速显示，停留一段时间（如之前所做）并关闭。在此之后我们有大约1分钟的延迟。然后，最后，应用程序窗口打开，一切都像魅力一样。
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.
我们的应用程序在Java 1.7.0u25之前没有遇到任何问题。 Java 1.7.0u40是问题出现的第一个版本。
Our application worked without problems up to Java 1.7.0u25. Java 1.7.0u40 was the first version where the problem showed up.
我们的应用程序是从一个（可执行的）jar文件构建的。最常见的部分是jar内部的串行端口访问的一些本机类。我在这篇文章末尾添加了jnlp文件。
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:
在我们的版本.html> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html 。
Checked the Java WebStart release notes at http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html for our versions.
我们可以说，没有什么可以导致这种行为。我们注意到有新的Manifest条目（Permissions，Codebase，Application-Name）。这些已被添加。
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.
查看Google和stackoverflow。
有些似乎有类似的问题，但我们从未见过解决方案。在许多情况下，人们在下载jar文件和重复下载时遇到问题。这似乎不是我们的问题。
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.
使用过的强硬工具
我们想要的知道应用程序在上述时间内做了什么。所以我们使用了来自sysinternals和wireshark的进程资源管理器和进程监视器。我们发现在等待时间内，该过程尝试通过IP与'vip1.g-anycast1.cachefly.net'（205.234.175.175）和93.184.220.29进行通信。后者似乎是一个证书服务器，我真的不明白cachefly是什么东西。在这两种情况下，我们都会看到TCP syn，但没有答案，没有进一步的沟通。这两个地址都是可ping的。
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.
与IP-stuff无关：我们确定，应用程序没有下载，而是从缓存启动，我们的主要是在延迟之后叫，而不是之前。
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.
这是我们陷入困境的地方
如何解决这个问题？我们是唯一遇到此行为的人吗？
Any further ideas how to solve this? Are we the only ones experiencing this behaviour?
Jnlp（请注意，网址是手动返工的）：
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>
推荐答案
是的，atulsm的回答是正确的。但请继续阅读：我试图遵循提示，但它看起来不太好，因为在Java控制面板中该条目已被禁用（未设置勾号）。 设置导致tickmark仅暂时显示（一旦WebStart应用程序被执行并再次终止，设置又回到未选中状态），所以看起来好像设置不正确写入Java的配置文件。
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.
最后：我检查了部署配置文件并设置 deployment.security.revocation.check = NO_CHECK 在部署属性中手动执行。这确实解决了这个问题！
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!
这篇关于自Java 1.7.0u40以来Java WebStart应用程序的启动延迟很长的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
