• wrapper.check.deadlock Eigenschaft
• wrapper.check.deadlock.interval Eigenschaft
• wrapper.check.deadlock.action Eigenschaft
• wrapper.check.deadlock.output Eigenschaft

Deadlock?

Deadlocks können auftreten, wenn zwei oder mehr Threads Ressourcen in einer Reihenfolge sperren, die zur Folge hat, dass alle Threads unbestimmte Zeit warten.

Das einfachste Beispiel ist wo: Thread A sperrt Objekt A und versucht dann das Objekt B zu sperren, während ein anderer Thread B das Objekt B gesperrt hat und darauf wartet, das Objekt A zu sperren. In diesem Fall wird Thread A Objekt A nie freigegeben, weil es auf Objekt B wartet. Dies wird nie der Fall sein, weil Thread B das Objekt B auf unendliche Zeit gesperrt lässt während es darauf wartet, dass das Objekt A wieder verfügbar wird.

Kompatibel :	3.5.0
Editionen :
Betriebssysteme :

Diese wrapper.check.deadlock Eigenschaft, in Kombination mit anderen Eigenschaften,

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

werden benutzt, um zu konfigurieren, wie der Wrapper eine JVM bezüglich Deadlocked-Threads überwacht. Dies kann sehr nützlich sein, um potentielle schwerwiegende Probleme zu entdecken und auf sie mit einem Workaround zu reagieren, die andererseits nur schwierig oder unmöglich mit einem Workaround zu behandeln wären.

Das Überprüfen nach Deadlocks ist ziemlich schnell, aber es beinhaltet kurzes Sperren und das Erstellen eines Speicherauszugs von allen Threads, so dass diese Eigenschaft standardmässig "FALSE" ist.

wrapper.check.deadlock=FALSE

Einfaches Beispiel:

Bitte lesen die Details zu den Eigenschaften unten; das folgende Beispiel konfiguriert den Wrapper, um den Ort eines Deadlocks zu loggen und dann sofort die JVM neu zu starten.

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

Kompatibel :	3.5.0
Editionen :
Betriebssysteme :

Die wrapper.check.deadlock.interval Eigenschaft macht es möglich, das Zeitintervall zu überwachen, während dem der Wrapper auf Deadlocks in einer Anwendung prüft. Dieses kann auf jedes beliebige Zeitintervall, beginnend von einmal pro Sekunde, eingestellt werden, aber der Standardwert ist "60" Sekunden (einmal pro Minute). Im Allgemeinen ist es für Anwendungen, die stabil erscheinen, in Ordnung, die Häufigkeit der Deadlock-Tests in größerem Maße zu verringern.

wrapper.check.deadlock.interval=60

Kompatibel :	3.5.0
Editionen :
Betriebssysteme :

Die wrapper.check.deadlock.action Eigenschaft macht es möglich, zu kontrollieren, was der Wrapper tut, wenn ein Deadlock erkannt wurde. Die Standardaktion ist NEUSTARTEN.

wrapper.check.deadlock.action=RESTART

Mögliche Aktionen sind:

• DEBUG :

  verursacht, dass eine Debug-Nachricht geloggt wird. Dies ist nur dann wirklich nützlich, wenn es Sie dabei unterstützt, zu verstehen, wann die Aktion ausgeführt wird.

• STATS (Seit Ver. 3.5.52, Standard und Professional Editionen) :
  ? Please check the English version for a more recent version of this text.

• DUMP :

  aktiviert einen Thread-Dump.

• GC (Seit Ver. 3.5.7) :

  aktiviert einen "Speicherbereinigungsvorgang" in der JVM. Bitte beachten Sie, dass dies, wenn es häufig getan wird, die Leistung der JVM beeinträchtigen kann, da ein vollständiger Durchlauf oft verursachen kann, dass alle Threads für die Dauer des GC angehalten werden.

• NEUSTART :

  hält die gegenwärtige JVM an und startet dann einen neuen Aufruf.

• HERUNTERFAHREN :

  hält sowohl die JVM wie auch den Wrapper an.

• USER_<n> (Professional Edition) :

  sorgt dafür, dass ein vom User festgelegtes Ereignis gestartet wird. Dies kann entweder das Absenden einer Email, oder das Ausführen eines externen Systembefehls sein. Der Befehl könnte alles sein, vom Ausführen von "Reinigungsvorgängen" bis zum Bereitstellen von SNMP-Traps.

• PAUSE :

  pausiert die Java-Anwendung, wenn das Pausieren aktiviert ist und die JVM im Betrieb ist. Sehen Sie in die wrapper.pausable Eigenschaft für mehr Details.

• RESUME :

  setzt die Java-Anwendung fort, wenn sich diese in einem unterbrochenem Zustand befindet. Dies könnte genutzt werden, wenn die JVM nicht komplett angehalten, sondern nur unterbrochen ist. Sehen Sie in die wrapper.pausable Eigenschaft für mehr Details.

• SUCCESS (Seit Ver. 3.5.5) :

  informiert den Wrapper darüber, seinen internen Zähler über mißlungene Ausfrufe zurückzusetzen und den gegenwärtigen Aufruf der JVM as "erfolgreich" zu zählen. Dies ist wahrscheinlich in diesem Kontext nicht nützlich, aber hier aus Gründen der Konsistenz mit anderen Eigenschaften.

• NONE :

  informiert den Wrapper darüber, die Tatsache zu loggen, dass ein Deadlock entdeckt wurde, aber es tut sonst weiter nichts.

Verkettung von mehrfachen Aktionen:

Es ist möglich, mehr als eine Aktion zu spezifizieren, indem man diese per Leerstelle oder per Komma trennt. Wenn mehr als eine Aktion spezifiziert wird, werden diese in schneller Abfolge in der spezifizierten Reihenfolge ausgeführt.

Das folgende Beispiel führt einen Thread-Dump durch und startet dann die JVM neu.

wrapper.check.deadlock.action=DUMP,RESTART

Kompatibel :	3.5.0
Editionen :
Betriebssysteme :

Die wrapper.check.deadlock.output Eigenschaft ermöglicht es, zu steuern, welche Information der Wrapper veranlässt, zu loggen, wenn ein Deadlock erkannt wurde. Der Standard-Ausgabeausmaß ist FULL.

wrapper.check.deadlock.output=FULL

Mögliche Ausgabemaße sind:

• FULL :

  Sorgt dafür, dass die WrapperManager-Klasse innerhalb der JVM einen Bericht ausgibt, der vollständige Stack-Traces für die Threads, die am Deadlock beteiligt sind, beinhaltet.

  Ausgabebeispiel eines "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 :

  hat zur Folge, dass die WrapperManager Klasse innerhalb der JVM einen Bericht ausgibt, der eine kurze Zusammenfassung mit Nennung der Threads und Objekte, die am Deadlock beteiligt sind, beinhaltet. In vielen Fällen ist dies ausreichend, insbesondere für bekannte Probleme.

  Ausgabebeispiel von "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 (Seit Ver. 3.5.16) :

  hat zur Folge, dass die WrapperManager-Klasse innerhalb der JVM jedwede Ausgabe unterdrückt. Dies kann für Produktionssysteme gewünscht sein, wenn ein Problem bekannt ist, und nicht zu viel Informationen in den Logs aufrechterhalten werden müssen. Der Wrapper-Vorgang wird, wie in den anderen Optionen, stets einen einzelnen Eintrag loggen, um einen Grund dafür anzugeben, warum die ausgelöste Aktion stattfindet.

  Ausgabebeispiel von "NONE":

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