自 Java 1.7.0u40 以来 Java WebStart 应用程序的长时间启动延迟 [英] Long startup delay for Java WebStart application since Java 1.7.0u40
问题描述
自从我们安装了 Java 1.7.0u45 后，我们的 WebStart 应用程序在 Windows 系统上的启动出现了严重延迟(我们还没有尝试过其他平台).
症状是双击桌面上的应用程序图标后，启动画面很快出现，停留一段时间(就像以前一样)然后关闭.在此之后，我们有大约 1 分钟的延迟.然后，最后，应用程序窗口打开，一切正常.
我们的应用程序在 Java 1.7.0u25 之前都没有问题.Java 1.7.0u40 是第一个出现问题的版本.
我们的应用程序是由一个(可执行的)jar 文件构建的.最重要的部分是 jar 中的一些用于串行端口访问的本机类.我在本文末尾添加了 jnlp 文件.
我们试图找出延迟的原因:
在 >http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html 对于我们的版本.
据我们所知，没有什么可以导致这种行为.我们注意到有新的清单条目(权限、代码库、应用程序名称).这些是添加的.
在 Google 和 stackoverflow 上到处找.
有些人似乎有类似的问题，但我们从未见过解决方案.在很多情况下，人们在下载 jar 文件和重复下载时会遇到问题.这似乎不是我们的问题.
使用过硬的工具
我们想知道应用在上述一分钟内做了什么.所以我们使用了来自 sysinternals 和 wireshark 的进程浏览器和进程监视器.我们发现在等待时间内，进程试图通过 IP 与vip1.g-anycast1.cachefly.net"(205.234.175.175)和 93.184.220.29 进行通信.后者似乎是一个证书服务器，我不是很明白那个cachefly是什么东西.在这两种情况下，我们都看到了 TCP 同步，但没有应答，也没有进一步的通信.两个地址都可以ping通.
与 IP 无关:我们确定，应用程序不是下载的，而是从缓存中启动的，并且我们的 main 是在延迟之后调用的，而不是之前.>
这就是我们被困的地方
还有什么办法可以解决这个问题吗?我们是唯一遇到这种行为的人吗?
Jnlp(注意url是手动修改的):
是的，atulsm 的回答是正确的.但请继续阅读:我试图按照提示进行操作，但它看起来并不好，因为在 Java 控制面板中，该条目已被禁用(未设置勾号).设置导致勾号只是暂时显示(一旦WebStart应用程序被执行并再次终止，设置就会回到未选中状态)，所以看起来好像设置不正确写入Java的配置文件.
最后:我检查了 部署配置文件 并在部署属性中手动设置deployment.security.revocation.check=NO_CHECK.那确实解决了问题！
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).
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.
Our application worked without problems up to Java 1.7.0u25. Java 1.7.0u40 was the first version where the problem showed up.
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:
Checked the Java WebStart release notes at http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html for our versions.
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.
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.
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.
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.
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):
<?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>
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.
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屋！
