Les Deadlocks de threads sont possibles dans toute application Java multithread. Ils constituent un problème depuis l'implémentation des premières applications multithread. Par exemple : une application peut passer par un cycle de tests complet, être publiée, subir des tests supplémentaires, puis finalement être déployée pour un usage critique. Au fur et à mesure que l'utilisation de l'application augmente, un composant critique cesse soudainement de répondre. Le seul recours de l'administrateur système est de tuer et de redémarrer l'application pour la faire fonctionner à nouveau.
Ce qui s'ensuit généralement, c'est que les utilisateurs de l'application se plaignent auprès de l'administrateur système de la gêne, de la perte de ventes ou d'autres préjudices causés par l'indisponibilité. Les développeurs de l'application sont informés qu'il y a eu un gel de l'application et qu'ils doivent le résoudre immédiatement. Malheureusement, il n'y a généralement que très peu, voire aucune, information sur ce qui a causé le gel de l'application. Les développeurs doivent essayer de résoudre le problème sans aucun indice sur sa cause, ni même sur la nature du problème. Cela conduit souvent à une réaction du type « essayez à nouveau et voyez ce qui se passe », ce qui n'est jamais bon pour quiconque est impliqué.
Lorsqu'un Deadlock est détecté par le Wrapper, celui-ci consigne d'abord un rapport détaillé indiquant exactement quels threads et quels objets étaient impliqués.
Il peut ensuite redémarrer immédiatement la JVM pour s'assurer que votre application Java est de nouveau opérationnelle avec un minimum d'indisponibilité.
Cela signifie que non seulement votre application Java restera opérationnelle,
mais que toutes les informations nécessaires pour signaler le problème, afin qu'il puisse être corrigé, seront également disponibles.
Qu'est-ce qu'un Deadlock ? |
|
Un deadlock se produit lorsque deux threads ou plus d'un programme se retrouvent bloqués en attendant d'accéder à un objet qui ne sera jamais disponible. Imaginez deux employés, Tom et Fred. Ils rédigent tous deux des notes pour gagner leur vie. Pour ce faire, ils doivent prendre un bloc-notes et un stylo sur un bureau, écrire la note, puis remettre le bloc-notes et le stylo sur le bureau. Tom et Fred sont tous deux très têtus. Une fois qu'ils ont commencé, ils ne remettront jamais le bloc-notes ou le stylo sur la table tant que la note n'aura pas été écrite. Que se passera-t-il si Tom prend le papier et Fred le stylo en même temps ? Tom va attendre indéfiniment le stylo, et Fred va attendre indéfiniment le papier. Ils se trouvent maintenant dans une situation de deadlock. Aucun des deux ne peut avancer, car aucun d'eux ne cédera jamais. Avec Tom et Fred, l'un d'eux finira par se lasser et remettra ce qu'il a sur le bureau. Mais les programmes ne fonctionnent pas ainsi. Deux threads qui se sont mis dans un tel état de « deadlock » continueront d'attendre jusqu'au milieu de la nuit. À un moment donné, leur responsable va remarquer qu'aucune note n'est prise et il y aura des ennuis. Ce qui rend ce type de problème de deadlock si difficile à reproduire et à corriger, c'est qu'il s'agit simplement d'une question de timing. Tom et Fred auraient pu travailler ensemble pendant des années sans aucun problème simplement parce qu'ils avaient très rarement besoin d'écrire une note en même temps. Cependant, lorsqu'on leur demande de prendre plusieurs notes par minute, le problème apparaît assez rapidement. Comment résoudre ce dilemme ? La solution consiste à dire à Tom et Fred que, lorsqu'ils prennent une note, ils doivent toujours essayer de prendre le bloc-notes avant le stylo. Il y aura encore des cas où l'un d'eux devra attendre un moment que l'autre remette le papier ou le stylo sur le bureau, mais ils ne se retrouveront jamais bloqués. |
Solution |
||
|
Dans cet exemple avec nos deux employés, le problème est très clair et peut être facilement résolu. Dans un logiciel applicatif de très grande envergure, impliquant des dizaines de ressources et des dizaines de milliers de lignes de code, il peut être très difficile d'identifier le problème, et encore plus de le résoudre. Les deadlocks réels peuvent parfois impliquer plusieurs ressources et threads utilisés dans des combinaisons qui n'avaient pas été anticipées par les développeurs du système. De par leur nature même, les deadlocks sont beaucoup plus susceptibles de se produire avec des données réelles que dans un environnement de test, car les données réelles tendent à présenter une plus grande variété et des volumes plus importants. Comme pour les employés, lorsqu'il y a peu de messages à enregistrer, le système fonctionne bien. Mais lorsque l'activité s'intensifie, il devient de plus en plus probable qu'un problème survienne. Demander aux deux employés de suivre les mêmes listes de tâches semble évident. Mais en réalité, les grands systèmes sont conçus par plusieurs développeurs, chacun créant sa propre liste de tâches. Tout ensemble d'opérations est correct en soi, mais peut causer des problèmes lorsqu'il est utilisé conjointement. Bien que le Java Service Wrapper ne soit pas en mesure d'empêcher un Deadlock au niveau de l'application de se produire, le Wrapper contient des fonctionnalités avancées de détection des Deadlocks qui permettent de détecter et de résoudre le problème avant même qu'un humain ne soit susceptible de remarquer que quelque chose ne va pas. En même temps, le Wrapper collecte et consigne une description détaillée de ce qui s'est exactement passé. Cela facilite grandement la compréhension et la correction rapide de la source du problème par un développeur. Le Wrapper a la capacité de surveiller une application entière en cours d'exécution avec pratiquement aucune pénalité de performance. Lorsqu'il détecte un deadlock dans l'application, il produit un rapport dans le fichier journal du Wrapper comme suit :
Une fois le Deadlock détecté, le Wrapper peut être configuré pour entreprendre l'une des nombreuses actions possibles. Dans la plupart des cas, l'envoi d'un e-mail de notification puis le redémarrage de l'application constituent la meilleure marche à suivre. L'e-mail, contenant la sortie ci-dessus, permettra assez facilement à un développeur de corriger le problème. Et le redémarrage aidera à réduire l'impact du problème sur les utilisateurs en remettant l'application en service sans aucun délai inutile. D'après le rapport, il est très facile de voir que le deadlock a été causé par les threads « Worker-1 » et « Worker-2 », et de voir exactement où, dans leurs piles d'appels respectives, ils se sont bloqués. La sortie indique même clairement quelles instances d'objets spécifiques sont en cause. En plus de tout cela, la JVM aura été redémarrée automatiquement, ce qui signifie que l'impact sur les utilisateurs a été limité aux transactions concernées et à quelques instants d'indisponibilité. Le Wrapper vous aide à détecter les problèmes critiques, notamment : |
Solution technique |
||||||||||||||||||||||||||||||
|
Ajouter la capacité de détecter les deadlocks avec le Java Service Wrapper est aussi simple que d'ajouter quelques propriétés de configuration à votre fichier de configuration du Wrapper. L'application d'exemple TestWrapper fournie avec le Java Service Wrapper a cette fonctionnalité activée par défaut. Il suffit de lancer l'application et de cliquer sur le bouton « Create Deadlock » pour la voir en action.
|
Référence : Interblocage |
|
Le Java Service Wrapper fournit un ensemble complet de propriétés de configuration qui vous permettent d'adapter le Wrapper à vos besoins exacts. Veuillez consulter la documentation des propriétés individuelles pour découvrir toutes les possibilités au-delà des exemples présentés ci-dessus.
|