• propriété wrapper.check.deadlock
• propriété wrapper.check.deadlock.interval
• propriété wrapper.check.deadlock.action
• propriété wrapper.check.deadlock.output

Interblocage ?

Les interblocages peuvent se produire lorsque deux threads ou plus verrouillent des ressources dans un ordre qui entraîne l'attente indéfinie de tous les threads.

L'exemple le plus simple est celui où le thread A verrouille l'objet A puis tente de verrouiller l'objet B, tandis qu'un autre thread B a verrouillé l'objet B et attend de verrouiller l'objet A. Dans ce cas, le thread A ne libérera jamais l'objet A car il attend l'objet B. Cela n'arrivera jamais car le thread B conservera l'objet B verrouillé indéfiniment en attendant que l'objet A devienne disponible.

Compatibilité :	3.5.0
Éditions :
Plateformes :

Cette propriété wrapper.check.deadlock, en combinaison avec les autres propriétés,

• wrapper.check.deadlock.interval,
• wrapper.check.deadlock.action, et
• wrapper.check.deadlock.output

sont utilisées pour configurer la façon dont le Wrapper surveille une JVM à la recherche de threads en interblocage. Cela peut s'avérer très utile pour détecter puis contourner des problèmes potentiellement fatals qui seraient autrement difficiles, voire impossibles, à contourner.

La vérification des interblocages est assez rapide, mais elle implique de verrouiller brièvement tous les threads et d'en prendre un instantané, c'est pourquoi cette propriété est définie sur FALSE par défaut.

wrapper.check.deadlock=FALSE

Exemple simple :

Veuillez lire les détails des propriétés ci-dessous, mais l'exemple simple suivant configurera le Wrapper pour consigner l'emplacement d'un interblocage puis redémarrer immédiatement la JVM.

wrapper.check.deadlock=TRUE
wrapper.check.deadlock.interval=60
wrapper.check.deadlock.action=RESTART
wrapper.check.deadlock.output=FULL

Compatibilité :	3.5.0
Éditions :
Plateformes :

La propriété wrapper.check.deadlock.interval permet de contrôler l'intervalle auquel le Wrapper recherche des interblocages dans une application. Elle peut être définie à n'importe quel intervalle à partir d'une fois par seconde, mais la valeur par défaut est « 60 » secondes (une fois par minute). En général, pour les applications connues pour être stables, il peut être acceptable de diminuer considérablement la fréquence de ces vérifications d'interblocage.

wrapper.check.deadlock.interval=60

Compatibilité :	3.5.0
Éditions :
Plateformes :

La propriété wrapper.check.deadlock.action permet de contrôler ce que le Wrapper fait lorsqu'un interblocage est détecté. L'action par défaut est RESTART.

wrapper.check.deadlock.action=RESTART

Les actions possibles sont :

• DEBUG :

  provoquera la consignation d'un message de débogage. Cela n'est vraiment utile que pour comprendre quand l'action est déclenchée.

• STATS (Depuis la ver. 3.5.52, Édition Standard / Professionnelle) :

  affichera les statistiques de performance.

• DUMP :

  invoquera un thread dump.

• GC (Depuis la ver. 3.5.7) :

  invoquera un cycle complet de ramasse-miettes (garbage collection) dans la JVM. Sachez que le faire fréquemment peut affecter les performances de la JVM, car un cycle complet entraînera souvent le gel de tous les threads pendant la durée du GC.

• RESTART :

  arrêtera la JVM actuelle, puis relancera une nouvelle invocation.

• SHUTDOWN :

  arrêtera la JVM ainsi que le Wrapper.

• USER_<n> (Édition Professionnelle) :

  provoquera le déclenchement d'un événement défini par l'utilisateur. Cela peut être soit l'envoi d'un e-mail, soit l'exécution d'une commande système externe. La commande peut aller d'opérations de nettoyage jusqu'à l'émission d'un trap SNMP.

• PAUSE :

  mettra en pause l'application Java si la pause est activée et que la JVM est en cours d'exécution. Consultez la propriété wrapper.pausable pour plus de détails.

• RESUME :

  reprendra l'application Java si elle est dans un état de pause. Cela peut être utilisé si la JVM n'est pas arrêtée lorsqu'elle est en pause. Consultez la propriété wrapper.pausable pour plus de détails.

• SUSPEND_TIMEOUTS_<n> (Depuis la ver. 3.5.40, Édition Standard / Professionnelle) :

  Indique au Wrapper de suspendre tous les délais d'attente utilisés lorsque la JVM ne répond pas. <n> spécifie le nombre de secondes pendant lesquelles les délais d'attente doivent être suspendus, et doit être compris dans la plage 1-3600 (1 h). Cela peut être utilisé si l'application Java doit effectuer une longue tâche bloquante et éviter que le Wrapper considère l'application comme ne répondant pas.

  Les délais d'attente peuvent également être suspendus via d'autres propriétés d'action, le fichier de commandes ou la méthode Java WrapperManager.suspendTimeouts().

  Si plusieurs demandes de suspension des délais d'attente sont effectuées, le nombre de secondes spécifié par chaque demande ne sera pas additionné. À la place, le temps nouvellement spécifié remplaçera le temps de suspension restant s'il est plus long, et sera ignoré dans le cas contraire.

• RESUME_TIMEOUTS (Depuis la ver. 3.5.40, Édition Standard / Professionnelle) :

  Indique au Wrapper de reprendre tous les délais d'attente précédemment suspendus.

  Les délais d'attente peuvent également être repris via d'autres propriétés d'action, le fichier de commandes ou la méthode Java WrapperManager.resumeTimeouts().

• SUCCESS (Depuis la ver. 3.5.5) :

  indiquera au Wrapper de réinitialiser son compteur interne d'invocations échouées et de compter l'invocation actuelle de la JVM comme « réussie ». Cela n'est probablement pas utile dans ce contexte, mais figure ici pour des raisons de cohérence avec les autres propriétés.

• NONE :

  indiquera au Wrapper de consigner le fait qu'un interblocage a été détecté, mais il ne fera concrètement rien.

Enchaînement de plusieurs actions :

Il est possible de spécifier plus d'une action en les séparant par un espace ou une virgule. Lorsque plusieurs actions sont spécifiées, elles seront exécutées en succession rapide dans l'ordre spécifié.

L'exemple suivant effectuera un thread dump, puis redémarrera la JVM.

wrapper.check.deadlock.action=DUMP,RESTART

Compatibilité :	3.5.0
Éditions :
Plateformes :

La propriété wrapper.check.deadlock.output permet de contrôler les informations que le Wrapper fait consigner lorsqu'un interblocage est détecté. Le niveau de sortie par défaut est FULL.

wrapper.check.deadlock.output=FULL

Les niveaux de sortie possibles sont :

• FULL :

  fera en sorte que la classe WrapperManager au sein de la JVM produise un rapport comprenant les traces de pile complètes des threads impliqués dans l'interblocage.

  Exemple de sortie de « FULL » :

  INFO | jvm 1 | WrapperManager Error: Found 2 deadlocked threads! INFO | jvm 1 | WrapperManager Error: ============================= INFO | jvm 1 | WrapperManager Error: "Locker-2" tid=18 INFO | jvm 1 | WrapperManager Error: java.lang.Thread.State: BLOCKED INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock.lockSecond(DeadLock.java:64) INFO | jvm 1 | WrapperManager Error: - waiting on <0x000000002fcac6db> (a java.lang.Object) owned by "Locker-1" tid=17 INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock.lockFirst(DeadLock.java:83) INFO | jvm 1 | WrapperManager Error: - locked <0x0000000029c56c60> (a java.lang.Object) INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock.access$100(DeadLock.java:22) INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock$1.run(DeadLock.java:42) INFO | jvm 1 | WrapperManager Error: INFO | jvm 1 | WrapperManager Error: "Locker-1" tid=17 INFO | jvm 1 | WrapperManager Error: java.lang.Thread.State: BLOCKED INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock.lockSecond(DeadLock.java:64) INFO | jvm 1 | WrapperManager Error: - waiting on <0x0000000029c56c60> (a java.lang.Object) owned by "Locker-2" tid=18 INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock.lockFirst(DeadLock.java:83) INFO | jvm 1 | WrapperManager Error: - locked <0x000000002fcac6db> (a java.lang.Object) INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock.access$100(DeadLock.java:22) INFO | jvm 1 | WrapperManager Error: at org.tanukisoftware.wrapper.test.DeadLock$1.run(DeadLock.java:42) INFO | jvm 1 | WrapperManager Error: INFO | jvm 1 | WrapperManager Error: ============================= STATUS | wrapper | A Thread Deadlock was detected in the JVM. Restarting JVM.

• SIMPLE :

  fera en sorte que la classe WrapperManager au sein de la JVM produise un rapport ne comprenant qu'un bref résumé nommant les threads et les objets impliqués dans l'interblocage. Dans de nombreux cas, cela suffit, en particulier pour les problèmes connus.

  Exemple de sortie de « SIMPLE » :

  INFO | jvm 1 | WrapperManager Error: Found 2 deadlocked threads! INFO | jvm 1 | WrapperManager Error: ============================= INFO | jvm 1 | WrapperManager Error: "Locker-2" BLOCKED waiting on a java.lang.Object owned by "Locker-1" INFO | jvm 1 | WrapperManager Error: "Locker-1" BLOCKED waiting on a java.lang.Object owned by "Locker-2" INFO | jvm 1 | WrapperManager Error: ============================= STATUS | wrapper | A Thread Deadlock was detected in the JVM. Restarting JVM.

• NONE (Depuis la ver. 3.5.16) :

  fera en sorte que la classe WrapperManager au sein de la JVM supprime toute sortie. Cela peut être souhaitable pour les systèmes de production lorsqu'un problème est connu mais que vous ne souhaitez pas ou n'avez pas besoin de conserver trop d'informations dans les journaux. Le processus Wrapper, comme pour les autres options, consignera toujours une seule entrée pour indiquer la raison pour laquelle l'action déclenchée a lieu.

  Exemple de sortie de « NONE » :

  STATUS | wrapper | A Thread Deadlock was detected in the JVM. Restarting JVM.