web-dev-qa-db-fra.com

java 11 HttpClient mène à une boucle SSL sans fin

J'utilise le nouveauJava.net.http.HttpClient Avec la méthode sendAsync. Le HttpClient est à l'intérieur d'un Singelton et est créé une fois comme ceci: HttpClient.newBuilder().build() donc vraiment rien de spécial.

Ces demandes peuvent être POST ou GET mais je ne sais pas ce qui cause le problème.

Il n'y a que quelques demandes par jour, mais de temps en temps un thread utilise 100% d'un cœur de processeur. Et pas de manière imminente mais après un certain temps lorsque la demande est terminée.

J'ai donc fait un vidage de thread quand il y avait même 2 de ces boucles sans fin se produisant, les 2 threads suivants se sont démarqués:

"HttpClient-4-Worker-5" #144 daemon prio=5 os_prio=0 cpu=511298.10ms elapsed=520.71s tid=0x00007f684403e800 nid=0x2d6b runnable  [0x00007f68ac162000]
   Java.lang.Thread.State: RUNNABLE
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer.processData([email protected]/SSLFlowDelegate.Java:771)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer$WriterDownstreamPusher.run([email protected]/SSLFlowDelegate.Java:645)
        at jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run([email protected]/SequentialScheduler.Java:147)
        at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run([email protected]/SequentialScheduler.Java:198)
        at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule([email protected]/SequentialScheduler.Java:271)
        at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule([email protected]/SequentialScheduler.Java:224)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer.triggerWrite([email protected]/SSLFlowDelegate.Java:722)
        at jdk.internal.net.http.common.SSLFlowDelegate.doHandshake([email protected]/SSLFlowDelegate.Java:1024)
        at jdk.internal.net.http.common.SSLFlowDelegate.doClosure([email protected]/SSLFlowDelegate.Java:1094)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader.unwrapBuffer([email protected]/SSLFlowDelegate.Java:500)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader.processData([email protected]/SSLFlowDelegate.Java:389)
        - locked <0x00000000fba68950> (a Java.lang.Object)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher.run([email protected]/SSLFlowDelegate.Java:263)
        at jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run([email protected]/SequentialScheduler.Java:175)
        - locked <0x00000000fbbca3e8> (a Java.lang.Object)
        at jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run([email protected]/SequentialScheduler.Java:147)
        at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run([email protected]/SequentialScheduler.Java:198)
        at Java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.Java:1128)
        at Java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.Java:628)
        at Java.lang.Thread.run([email protected]/Thread.Java:834)

   Locked ownable synchronizers:
        - <0x00000000fc1ff920> (a Java.util.concurrent.ThreadPoolExecutor$Worker)





"HttpClient-4-Worker-2" #82 daemon prio=5 os_prio=0 cpu=4266156.67ms elapsed=4311.42s tid=0x00007f6844007000 nid=0x29ee runnable  [0x00007f686fffd000]
   Java.lang.Thread.State: RUNNABLE
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer.processData([email protected]/SSLFlowDelegate.Java:771)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer$WriterDownstreamPusher.run([email protected]/SSLFlowDelegate.Java:645)
        at jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run([email protected]/SequentialScheduler.Java:147)
        at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run([email protected]/SequentialScheduler.Java:198)
        at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule([email protected]/SequentialScheduler.Java:271)
        at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule([email protected]/SequentialScheduler.Java:224)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer.triggerWrite([email protected]/SSLFlowDelegate.Java:722)
        at jdk.internal.net.http.common.SSLFlowDelegate.doHandshake([email protected]/SSLFlowDelegate.Java:1024)
        at jdk.internal.net.http.common.SSLFlowDelegate.doClosure([email protected]/SSLFlowDelegate.Java:1094)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader.unwrapBuffer([email protected]/SSLFlowDelegate.Java:500)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader.processData([email protected]/SSLFlowDelegate.Java:389)
        - locked <0x00000000f97668d0> (a Java.lang.Object)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher.run([email protected]/SSLFlowDelegate.Java:263)
        at jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run([email protected]/SequentialScheduler.Java:175)
        - locked <0x00000000f97668f0> (a Java.lang.Object)
        at jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run([email protected]/SequentialScheduler.Java:147)
        at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run([email protected]/SequentialScheduler.Java:198)
        at Java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.Java:1128)
        at Java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.Java:628)
        at Java.lang.Thread.run([email protected]/Thread.Java:834)

   Locked ownable synchronizers:
        - <0x00000000f9894cc0> (a Java.util.concurrent.ThreadPoolExecutor$Worker)

Même constat mais sur un autre container où un seul thread a été affecté.

"HttpClient-3-Worker-2" #120 daemon prio=5 os_prio=0 cpu=1100568.51ms elapsed=1113.79s tid=0x00007eff3003b800 nid=0x479 runnable  [0x00007eff83bf8000]
   Java.lang.Thread.State: RUNNABLE
        at Sun.security.ssl.SSLEngineImpl.wrap([email protected]/SSLEngineImpl.Java:136)
        - eliminated <0x00000000f9796e08> (a Sun.security.ssl.SSLEngineImpl)
        at Sun.security.ssl.SSLEngineImpl.wrap([email protected]/SSLEngineImpl.Java:116)
        - locked <0x00000000f9796e08> (a Sun.security.ssl.SSLEngineImpl)
        at javax.net.ssl.SSLEngine.wrap([email protected]/SSLEngine.Java:519)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer.wrapBuffers([email protected]/SSLFlowDelegate.Java:821)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer.processData([email protected]/SSLFlowDelegate.Java:736)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer$WriterDownstreamPusher.run([email protected]/SSLFlowDelegate.Java:645)
        at jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run([email protected]/SequentialScheduler.Java:147)
        at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run([email protected]/SequentialScheduler.Java:198)
        at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule([email protected]/SequentialScheduler.Java:271)
        at jdk.internal.net.http.common.SequentialScheduler.runOrSchedule([email protected]/SequentialScheduler.Java:224)
        at jdk.internal.net.http.common.SSLFlowDelegate$Writer.triggerWrite([email protected]/SSLFlowDelegate.Java:722)
        at jdk.internal.net.http.common.SSLFlowDelegate.doHandshake([email protected]/SSLFlowDelegate.Java:1024)
        at jdk.internal.net.http.common.SSLFlowDelegate.doClosure([email protected]/SSLFlowDelegate.Java:1094)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader.unwrapBuffer([email protected]/SSLFlowDelegate.Java:500)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader.processData([email protected]/SSLFlowDelegate.Java:389)
        - locked <0x00000000f9797010> (a Java.lang.Object)
        at jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher.run([email protected]/SSLFlowDelegate.Java:263)
        at jdk.internal.net.http.common.SequentialScheduler$SynchronizedRestartableTask.run([email protected]/SequentialScheduler.Java:175)
        - locked <0x00000000f9797030> (a Java.lang.Object)
        at jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run([email protected]/SequentialScheduler.Java:147)
        at jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run([email protected]/SequentialScheduler.Java:198)
        at Java.util.concurrent.ThreadPoolExecutor.runWorker([email protected]/ThreadPoolExecutor.Java:1128)
        at Java.util.concurrent.ThreadPoolExecutor$Worker.run([email protected]/ThreadPoolExecutor.Java:628)
        at Java.lang.Thread.run([email protected]/Thread.Java:834)

Un exemple de code que j'utilise

httpClient.sendAsync(request, HttpResponse.BodyHandlers.ofString())
                                .thenApply(logResponse());

Version Java

openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment (build 11.0.2+9-Debian-3)
OpenJDK 64-Bit Server VM (build 11.0.2+9-Debian-3, mixed mode, sharing)

Le problème se produit également lorsque vous préférez HTTP 2

Mises à jour

Suis-je en train d'utiliser le HttpClient de manière incorrecte? Serait-ce un problème de serveur? Est-ce peut-être ce bug https://bugs.openjdk.Java.net/browse/JDK-8207009 ?

  • Le client se connecte à un service cloudflare
  • Lorsque le problème se produit, il n'y a pas de connexion ouverte à cloudflare via netstat visible
  • Je peux épingler le problème à http2 + tlsv1.3 (en utilisant l'image docker nginx: nginx:1.15-Alpine Avec tls1.3 activé bien sûr)
javamultithreadinghttphttp2java-11
17
Zarathustra

Comme l'a dit @jspcal avant de désactiver TLS 1.3.

tl; dr: désactiver tlsv1.3 via l'extension/l'écrasement

<Java_home>/conf/security/Java.security les jdk.tls.disabledAlgorithms propriété

Étant donné que mon application s'exécute dans un conteneur Docker, j'ai changé l'image de base pour désactiver tls1.3

FROM openjdk:11-jre
...

RUN sed -i "/jdk.tls.disabledAlgorithms=/ s/=.*/=TLSv1.3, SSLv3, RC4, MD5withRSA, DH keySize < 1024, EC keySize < 224, DES40_CBC, RC4_40, 3DES_EDE_CBC/" $(readlink -f /usr/bin/Java | sed "s:bin/Java::")/conf/security/Java.security

Autant que je sache, il n'y a aucun moyen de définir cette propriété (de sécurité) via une propriété système! Voir également Sun.security.util.DisabledAlgorithmConstraints#PROPERTY_TLS_DISABLED_ALGS qui a réellement préparé la propriété.

Mise à jour: Le bogue est toujours présent dans 11.0.2

6
Zarathustra

Essayez de désactiver TLSv1.3 ou SSLv3 pour voir si cela aide.

Définissez la propriété système sur la ligne de commande: -Djdk.tls.disabledAlgorithms=TLSv1.3

Ou définissez la propriété dans <Java_home>/conf/security/Java.security

Si vous pensez qu'il s'agit d'un bogue d'implémentation, vous souhaiterez peut-être ouvrir un problème.

6
jspcal