Cet article se veut pragmatique et est un retour d’expérience terrain.
Il n’a pas la vocation à expliquer les concepts de base des pools de connexion, des Threads ou des work managers qui ont déjà été expliqués par mes collègues.

 

Posons le sujet :

Il arrive fréquemment que nos clients observent des Stuck Threads sur le serveur sans savoir réellement si cela impacte leur production et comment y remédier.

L’analyse des Stuck Threads nécessite une analyse approfondie de votre infrastructure et de votre architecture. C’est un travail d’expert qui est réalisé lors de mission de conseils techniques.

Easyteam, par sa vocation, peut vous aider. Nous fournissons ce service à nos clients.

 

Qu’est-ce qu’un Stuck Threads ?

Le Stuck Threads est un révélateur de performance de votre application.

Il concerne une ressource allouée à votre application mais surtout traduit son occupation, c’est à dire comment vous l’utilisez.

 

Comment cela se traduit-il ?

Weblogic Server surveille vos traitements, plus exactement vos fils : les « thread » de processus. Dès lors qu’un fil est occupé depuis un certain temps, Weblogic le considère bloqué : c’est le « Stuck ».

Un Stuck Threads est donc la traduction d’une occupation considérée anormale par le serveur. Mais voilà, une valeur anormale pour votre serveur peut être acceptable par vous-même…

 

Quelle est l’origine des Stuck Threads ?

Il peut y avoir de nombreuses raisons pour lesquelles un fil est bloqué.

Cependant, l’origine est souvent une ressource indisponible.

Très communément, il faut orienter les recherches vers les pools JDBC, les connexions externes : les web services, les sockets, et caetera.

Mais une ressource peut aussi simplement être occupée par un traitement long de votre application. Dans ce cas, c’est un comportement normal, voire attendu.

 

Comment identifier les Stuck Threads ?

Le Stuck Threads doit être une alerte pour votre équipe.

Il faut rechercher son origine, c’est à dire identifier la ressource bloquée.

•  Tout d’abord, il faut consulter et analyser la log.
• Ensuite, et pour aller plus loin, il est conseillé d’effectuer une opération de ‘vidage’ du fil : c’est le  « threads dump ». On peut s’aider d’outils spécialisés comme thredlogic ou jmeter. Il est également possible de créer une notification de type « Diagnostic Image » à partir de la console Weblogic.

Ces informations vous permettent d’isoler la « root cause » de l’avertissement.

 

Est-ce grave ?

Tout d’abord, est-ce que mon serveur Weblogic va tomber, i.e. passer au statut FAILED ?

C’est une fausse idée préconçue…

• Tout d’abord, non, car Weblogic est configuré ainsi : la valeur par défaut de Failure Action est Ignore, take no action.
• Ensuite, un délai définit l’alerte : c’est le MaxStuckThreadTime (600 secondes par défaut).
• Enfin, il existe un seuil pour le nombre de Threads à partir duquel le serveur va réagir. La valeur par défaut de Stuck Threads Count est de à 0 (zéro). L’état FAILED se déclenchera uniquement si cette valeur est positive ! Encore une fois, seul l’état « Health » de votre serveur passera à WARNING.

C’est à vous de faire ces ajustements.

Ensuite, il y a une seconde question : est-ce que le service est rendu ?

Il faut pondérer : ce n’est pas parce qu’un fil est bloqué qu’il est inutilisable ; tout dépend du comportement qui s’en suit !

 

Est-ce que la situation va se rétablir d’elle même ?

Tout d’abord, ne tuez pas vos Threads en exécution : ce n’est pas faisable en java.

• Ensuite, et normalement, les Threads bloqués disparaissent si les conditions de blocages sont levées. Alors oui : ici, le service est rendu… mais nous vous dispense pas d’une analyse approfondie de l’organe du problème et d’y remédier.
• Cependant le nombre de threads bloqués peut augmenter jusqu’à bloquer votre application puis votre serveur Weblogic. Cela peut être le cas si la capacité mémoire de la JVM est atteinte… Alors non : ici vous êtes bloqué ! Dans ce cas, il pourrait être judicieux de redémarrer le noeud (node) impacté.

 

Illustration :

Un client rencontre un grand nombre de Stuck Threads dans ces logs :

1. La lecture de la trace montre l’origine : un pool JDBC. Cela traduit que la connexion vers la base de données est bloquée.
2. Il faut alors analyser la stack trace pour détecter des problèmes. Nous relevons l’erreur java.net.SocketInputStream.socketRead0.
3. La base de données n’a pas répondu à l’ouverture demandée par la pool jdbc du serveur Weblogic. L’origine est donc un problème externe. Dans ce cas, il faut se rapprocher de l’administrateur de la base de données. Celui-ci détectera des blocages de sessions et y remédiera.
4. Comme la situation perdure au delà des seuils, il est logique que le threads soit considéré comme bloqué par le serveur Weblogic qui porte la connexion jdbc bien que le problème ait pour origine un dysfonctionnement de la base de données.

Nb : un autre axe de réflexion aurait pu être le réseau puisque l’indicateur est une erreur de Socket.

 

Conclusion :

Un Stuck Threads traduit l’occupation d’un fil à un instant ‘t’.

Là est souvent l’erreur : il traduit l’occupation d’une ressource, pas obligatoirement un blocage !

Il faut être alerté lorsque l’occupation de la ressource est anomale. C’est une question de sensibilité. Il faut rechercher pourquoi le Thread prend un temps jugé anormal pour traiter le travail qui lui est assigné.

Bien entendu, le scénario catastrophe sera l’occupation complète des ressources du serveur Weblogic jusqu’à son « plantage » mais ce n’est pas systématique !

La bonne pratique est toujours de trouver les causes du fil bloqué et d’y remédier pour les éviter complètement plutôt que de réagir à une alerte du serveur.

Une fois votre infrastructure et votre application optimisées, alors il conviendra de s’assurer du « fine tuning » de votre serveur puis définir le comportement face aux Stuck Threads jugé ‘anormaux’.

 

Voilà, nous espérons que ce petit article sera une bonne introduction pour le gestion des fils, des occupation de ressources, un ébauche d’analyse et surtout un guide sur le fine tuning de votre serveur et les comportements à adopter.

 

Pour aller plus loin :

1. OSB : « Stuck Threads » sur la consommation de fichiers : https://easyteam.fr/osb-stuck-threads-sur-la-consommation-de-fichiers/
2. Sensibilisation autour du Work Manager https://easyteam.fr/sensibilisation-autour-du-work-manager/