简体   繁体   English

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

[英]Long startup delay for Java WebStart application since Java 1.7.0u40

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. 在此之后我们有大约1分钟的延迟。 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.0u25之前没有遇到任何问题。 Java 1.7.0u40 was the first version where the problem showed up. Java 1.7.0u40是问题出现的第一个版本。

Our app is constructed from a single (executable) jar file. 我们的应用程序由单个(可执行)jar文件构成。 The most exiting part are some native classes for serial port access that are inside the jar. 最常见的部分是jar中的一些用于串行端口访问的本机类。 I added the jnlp file at the end of this post. 我在这篇文章的末尾添加了jnlp文件。

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. 检查了我们版本的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). 我们注意到有新的Manifest条目(Permissions,Codebase,Application-Name)。 These were added. 这些都被添加了。

Looked all over Google and stackoverflow. 看着谷歌和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. 在许多情况下,人们在下载jar文件和重复下载时遇到问题。 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. 所以我们使用了sysinternals和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. 我们发现在等待时间内,该过程尝试通过IP与'vip1.g-anycast1.cachefly.net'(205.234.175.175)和93.184.220.29进行通信。 The latter seems to be a certificate server, I did not really understand what that cachefly thing is. 后者似乎是一个证书服务器,我真的不明白cachefly是什么东西。 In both cases we see a TCP syn, but no answer, no further communication. 在这两种情况下,我们都会看到TCP syn,但没有答案,没有进一步的沟通。 Both adddresses are pingable. 这两个地址都是可以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 after the delay, not before. 与IP-stuff无关:我们确定,应用程序没有下载,而是从缓存启动,并且我们的主要是延迟之后调用,而不是之前。

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>

Yes, atulsm's answer gave the right kick. 是的,atulsm的答案给了正确的答案。 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). 但请继续阅读:我试图遵循提示,但它看起来不太好,因为在Java控制面板中,条目已被禁用(未设置勾号)。 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. 设置它导致tickmark只是暂时显示(一旦WebStart应用程序被执行并再次终止,设置就会回到未选中状态),所以好像设置没有正确写入Java的配置文件中。

FINALLY: I checked the Deployment Configuration File and set deployment.security.revocation.check=NO_CHECK manually in the deployment properties. 最后:我检查了部署配置文件,并在部署属性中手动设置deployment.security.revocation.check=NO_CHECK That did solve the problem! 那确实解决了问题!

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 ! 禁用它(高级选项卡=>执行证书吊销检查“),它应该没问题!

This occurred with the version 1.8.0_221 as well in the web start application. 这与版本1.8.0_221以及Web启动应用程序一样。 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. 我已经完成了,我发现的问题是每次下载webstart应用程序时都没有从缓存中加载。 Here are a few changes that i made in the deployment.properties file I added these two thing in it 以下是我在deployment.properties文件中进行的一些更改,我在其中添加了这两项内容

deployment.security.tls.revocation.check=NO_CHECK deployment.security.revocation.check=NO_CHECK deployment.security.tls.revocation.check = NO_CHECK deployment.security.revocation.check = NO_CHECK
deployment.security.mixcode=DISABLE 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 您可以从configure 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. 这大大缩短了时间,但仍需要4分钟才能打开应用程序。 But before that it was taking more than 15 so it's a big improvement. 但在此之前它需要超过15个,所以这是一个很大的进步。 This is an extension to Micheal B's answer 这是Micheal B答案的延伸

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM