pointeur null dans le processeur java NIO SSO
Essayer d'exécuter gitblit, sur tomcat 9, en utilisant JDK 11 entraîne occasionnellement cette trace de pile:
gitblit | 07-May-2020 04:30:39.247 SEVERE [https-jsse-nio-8443-exec-10] org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun Error running socket processor
gitblit | java.lang.NullPointerException
gitblit | at java.base/sun.security.ssl.HKDF.extract(HKDF.java:93)
gitblit | at java.base/sun.security.ssl.HKDF.extract(HKDF.java:119)
gitblit | at java.base/sun.security.ssl.ServerHello.setUpPskKD(ServerHello.java:1167)
gitblit | at java.base/sun.security.ssl.ServerHello$T13ServerHelloProducer.produce(ServerHello.java:545)
gitblit | at java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
gitblit | at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.goServerHello(ClientHello.java:1234)
gitblit | at java.base/sun.security.ssl.ClientHello$T13ClientHelloConsumer.consume(ClientHello.java:1170)
gitblit | at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.onClientHello(ClientHello.java:852)
gitblit | at java.base/sun.security.ssl.ClientHello$ClientHelloConsumer.consume(ClientHello.java:813)
gitblit | at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
gitblit | at java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
gitblit | at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1061)
gitblit | at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask$DelegatedAction.run(SSLEngineImpl.java:1048)
gitblit | at java.base/java.security.AccessController.doPrivileged(Native Method)
gitblit | at java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:995)
gitblit | at org.apache.tomcat.util.net.SecureNioChannel.tasks(SecureNioChannel.java:443)
gitblit | at org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:507)
gitblit | at org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238)
gitblit | at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1616)
gitblit | at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
gitblit | at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
gitblit | at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
gitblit | at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
gitblit | at java.base/java.lang.Thread.run(Thread.java:834)
Lorsque les clients essaient d'extraire des fichiers de l'interface graphique gitblit.
Peut-être intéressant, jusqu'à ce que je mette à jour vers la version 11.0.7 du JDF, je voyais cette erreur: J'ai besoin d'un serveur de connexion HTTP/2 pour ouvrir JDK 11.util.NoSuchElementException
Où la correction de la mauvaise utilisation de l'option ici: https://bugs.openjdk.java.net/browse/JDK-8218889 {[7] } mais peut-être, n'a-t-il pas réellement abordé le problème racine?
Ou toute autre pensée quant à ce qui déclenche cette erreur? J'utilise un certificat auto-signé ici, pour info. Le client est Firefox, et la version java est
Openjdk version "11.0.7" 2020-04-14 Environnement d'exécution OpenJDK AdoptOpenJDK (build 11.0.7 + 10) Le serveur OpenJDK 64 bits adopte OpenJDK (build 11.0.7 + 10, mode mixte)
S'exécutant dans un docker alpine linux système.
Traquer un problème où gitblit a occasionnellement des délais d'attente de 1 minute, et trouver cela dans le journal. Je ne sais pas si lié, ou non....
Dirait qu'il a également été trouvé dans tomcat https://bz.apache.org/bugzilla/show_bug.cgi?id=64105, et rapportés ici
Https://bugs.openjdk.java.net/browse/JDK-8241248
Puisque je ne peux pas fournir d'informations sur le tracker de bogues openjdk, je peux vous dire que le client qui le provoque généralement pour moi est Firefox 75 sous linux.
1 answers
Comme indiqué par les références bugtracker que vous fournissez, il s'agit d'un bogue lié à la reprise de session.
Bien que cette réponse ne traite pas du bogue lui-même, il est possible de demander au SSLEngine d'interdire la reprise pour une connexion particulière. Cela entraîne une pénalité de performance pour les connexions futures, car le client doit rétablir la prise de contact pour les nouvelles connexions au lieu de tirer parti du mécanisme de reprise de session.
À tout moment après le la prise de contact est établie, vous pouvez appeler invalidate() sur la session SSLSession. Comme indiqué dans le doc:
Les connexions futures ne pourront pas reprendre ou rejoindre cette session. Cependant, toute connexion existante utilisant cette session peut continuer à utiliser la session jusqu'à ce que la connexion soit fermée.
Ce qui signifie qu'il n'a aucun effet sur la connexion actuelle , mais empêchera la reprise de session et évitera ainsi le bogue JDK.
Mon extrait pour la poignée de main boucle:
case NOT_HANDSHAKING:
case FINISHED:
{
if( !sslEngine.getSession().isValid() || sslEngine.getSession().getId().length == 0 )
throw new SSLHandshakeException("Handshake failed");
// prevent bug with rejoin session
sslEngine.getSession().invalidate();
return;
}