Длительная задержка запуска для приложения Java WebStart, так как Java 1.7.0u40
Поскольку мы установили Java 1.7.0u45, наше приложение WebStart показывает большую задержку при запуске в системах Windows (мы еще не пробовали другие платформы).
Признак состоит в том, что после двойного щелчка на значке приложения на рабочем столе всплывающий экран появляется быстро, остается на некоторое время (как и раньше) и закрывается. После этого у нас есть отсрочка около 1 минуты. Затем, наконец, открывается окно приложения, и все работает как шарм.
Наше приложение работало без проблем до Java 1.7.0u25. Java 1.7.0u40 была первой версией, в которой возникла проблема.
Наше приложение построено из одного (исполняемого) файла jar. Самой последней частью являются некоторые родные классы для доступа к последовательному порту, которые находятся внутри банки. Я добавил файл jnlp в конце этого сообщения.
Мы попытались выяснить причину задержки:
Проверено примечания по выпуску Java WebStart на http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html для наших версий.
Насколько мы можем сказать, нет ничего, что могло бы привести к поведению. Мы заметили, что есть новые записи Manifest (Разрешения, Codebase, Application-Name). Они были добавлены.
Посмотрел по всему Google и stackoverflow.
У некоторых, похоже, есть аналогичная проблема, но мы никогда не видели решения. Во многих случаях у людей возникают проблемы с загрузкой файлов jar и повторной загрузкой. Это, похоже, не наша проблема.
Используемые жесткие инструменты
Мы хотели узнать, что делает приложение в указанную минуту. Таким образом, мы использовали анализатор процессов и монитор процессов из sysinternals и wirehark. Мы выяснили, что в ожидаемое время процесс пытается связываться через IP с помощью "vip1.g-anycast1.cachefly.net" (205.234.175.175) и 93.184.220.29. Последний, кажется, сервер сертификатов, я действительно не понимал, что это за кеширование. В обоих случаях мы видим TCP syn, но ответа нет, нет дальнейших сообщений. Оба аддресса являются pingable.
Не относится к IP-материалам: мы уверены, что приложение не загружено, а запущено из кеша и что наша основная функция вызывается после задержки, а не раньше.
Здесь мы застреваем
Любые дальнейшие идеи, как это решить? Мы единственные, кто испытывает такое поведение?
Jnlp (обратите внимание, что URL-адреса вручную переработаны):
<?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="#" onclick="location.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'; return false;"/>
<icon kind="shortcut" href="#" onclick="location.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'; return false;"/>
<icon kind="splash" href="#" onclick="location.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'; return false;"/>
<homepage href="#" onclick="location.href='https://confluence.detss.corpintra.net/display/TCU/TcuTerm'; return false;"/>
<offline-allowed/>
<shortcut>
<desktop/>
<menu submenu="TcuTerm"/>
</shortcut>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.6+" href="#" onclick="location.href='http://java.sun.com/products/autodl/j2se'; return false;"/>
<jar href="TcuTerm.jar" main="true"/>
</resources>
<application-desc main-class="com.x.tcu.app.term.TcuTerminal"/>
<update check="timeout"/>
</jnlp>
Ответы
Ответ 1
Да, ответ atulsm дал правильный удар. Но читайте дальше: Я пытался следовать подсказке, но это выглядело не очень хорошо, поскольку в панели управления Java запись уже отключена (галочка не была установлена). При установке этого параметра тик файл показывался только временно (как только приложение WebStart было запущено и снова завершено, настройка вернулась к не выбранной), поэтому кажется, что этот параметр неправильно записан в конфигурационный файл Java.
НАКОНЕЦ: Я проверил Файл конфигурации развертывания и вручную установил deployment.security.revocation.check=NO_CHECK в свойствах развертывания. Это решило проблему!
Ответ 2
Я столкнулся с этой проблемой, и это произошло из-за проверки аннулирования сертификата по умолчанию. Отключите это (расширенная вкладка = > Выполнить проверку отзыва сертификатов "), и это должно быть хорошо!
Ответ 3
Это произошло и с версией 1.8.0_221 в приложении веб-запуска. Я сделал это, и проблема, которую я обнаружил, состояла в том, что каждый раз, когда приложение веб-запуска загружалось и не загружалось из кэша.
Вот несколько изменений, которые я сделал в файле deploy.properties
Я добавил эти две вещи в него
deployment.security.tls.revocation.check=NO_CHECK
deployment.security.revocation.check=NO_CHECK
deployment.security.mixcode=DISABLE
Вы также можете изменить эти настройки с помощью инструмента настройки Java.
В файле jnlp я изменил эти две вещи
1. изменил настройку проверки обновлений на фон с всегда
2. Увеличен размер кучи со 128 и 256 соответственно
<update check="background"/>
<j2se version="1.8+" initial-heap-size="256m" max-heap-size="512m"/>
Затем я пошел в командную строку и набрал эти
javaws -import -system -shortcut jnlp.jnlp
javaws -system -Xnosplash -wait jnlp.jnlp
Первая команда импортирует jnlp в системный кеш, а вторая вынуждает запускать jnlp из системного кеша, а не из приложения или путем его первой загрузки.
Чтобы быть в безопасности, сначала запустите эту команду, чтобы также удалить неустановленные приложения из кэша
javaws -clearcache
Это значительно сократило время, но для открытия приложения все еще требуется 4 минуты. Но до этого потребовалось более 15, так что это большое улучшение.
Это продолжение ответа Михаила Б
