java - ejemplo - jnlp windows 10
Retraso de inicio prolongado para la aplicaciĆ³n Java WebStart desde Java 1.7.0u40 (2)
He experimentado este problema y se debió a las verificaciones de revocación de certificados implementadas de forma predeterminada. Desactívelo (pestaña avanzada => Realizar comprobaciones de revocación de certificados en ") y debería estar bien!
Desde que instalamos Java 1.7.0u45, nuestra aplicación WebStart muestra un retraso importante en el inicio de los sistemas Windows (no hemos probado otras plataformas).
El síntoma es que después de hacer doble clic en el ícono de la aplicación en el escritorio, la pantalla de inicio aparece rápidamente, permanece por algún tiempo (como lo hizo antes) y se cierra. Después de esto tenemos un retraso de aproximadamente 1 minuto. Entonces, finalmente, la ventana de la aplicación se abre y todo funciona como un encanto.
Nuestra aplicación funcionó sin problemas hasta Java 1.7.0u25. Java 1.7.0u40 fue la primera versión donde apareció el problema.
Nuestra aplicación está construida a partir de un único archivo jar (ejecutable). La parte más interesante son algunas clases nativas para el acceso a puertos serie que están dentro del contenedor. Agregué el archivo jnlp al final de esta publicación.
Intentamos averiguar cuál podría ser la causa del retraso:
Revisó las notas de la versión de Java WebStart en http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/enhancements-7.html para nuestras versiones.
Por lo que podemos decir, no hay nada que pueda causar el comportamiento. Notamos que hay nuevas entradas de Manifiesto (Permisos, Base de código, Nombre de la aplicación). Estos fueron añadidos.
Miró por todo Google y stackoverflow.
Algunos parecen tener un problema similar, pero nunca vimos una solución. En muchos casos, las personas tienen problemas con la descarga de archivos jar y la descarga repetida. Este parece no ser nuestro problema.
Herramientas duras usadas
Queríamos saber qué hace la aplicación en dicho minuto de tiempo. Así que utilizamos el explorador de procesos y el monitor de procesos de sysinternals y wireshark. Descubrimos que, en el tiempo de espera, el proceso intenta comunicarse por IP con ''vip1.g-anycast1.cachefly.net'' (205.234.175.175) y 93.184.220.29. Este último parece ser un servidor de certificados, realmente no entendí qué es esa cosa cachefly. En ambos casos, vemos una sincronización TCP, pero no hay respuesta, no hay más comunicación. Ambas direcciones son pingables.
No relacionado con el IP-stuff: Estamos seguros de que la aplicación no se descarga, sino que se inicia desde el caché y que se llama a nuestro main después de la demora, no antes.
Aquí es donde estamos atrapados.
¿Alguna otra idea de cómo resolver esto? ¿Somos los únicos que experimentamos este comportamiento?
Jnlp (Tenga en cuenta que las direcciones URL se han modificado manualmente):
<?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>
Sí, la respuesta de Atulsm dio la patada correcta. Pero sigue leyendo: intenté seguir la sugerencia, pero no se veía bien ya que en el Panel de Control de Java la entrada ya estaba deshabilitada (la marca no estaba establecida). La configuración hizo que la marca de verificación solo se mostrara temporalmente (tan pronto como la aplicación WebStart se ejecutó y terminó de nuevo, la configuración volvió a no estar seleccionada), por lo que parece que la configuración no está escrita correctamente en el archivo de configuración de Java.
FINALMENTE: verifiqué el archivo de configuración de la implementación y configuré la configuración deployment.security.revocation.check=NO_CHECK
en las propiedades de la implementación. ¡Eso resolvió el problema!