wrapper.filter.<x>.<n> Eigenschaften Übersicht

Filter sind ein sehr leistungsstarkes Feature, welches es ermöglicht, ein neues Verhalten zu vorhandenen Anwendungen ohne Programmieraufwand hinzuzufügen. Es funktioniert durch die Überwachung der Konsolenausgabe einer JVM nach Textsequenzen. Sobald sie gefunden wurden, kann eine Anzahl von Aktionen unternommen werden.

Beispiele leiten das Neustarten der JVM ein, wann immer ein spezifischer Fehler auftritt. Einige Anwendungen haben bekannte Programmierfehler, bei denen sie aufhören, zu funktionieren, sobald sie in einen bestimmten Zustand kommen. Dieses Feature ermöglicht es, auf solche Probleme umgehend einen Workaround parat zu haben, solange bis sie in der Anwendung gelöst werden können.

Genutzte Eigenschaften, um Filter, wie unten beschrieben, zu konfigurieren:

Zu allermindestens muss ein Filter wrapper.filter.trigger.<n> und wrapper.filter.action.<n> Eigenschaften definieren. Die anderen sind optional.

<n> Komponente:

In jedem Filter ist die "<n>" Komponente des Eigenschaftennamens eine ganze Integer-Zahl, die hochzählt von "1". Standardmäßig darf es keine fehlenden Zahlen geben. Die wrapper.ignore_sequence_gaps Eigenschaft kann optional gesetzt werden, um Lücken in der Sequenz zu erlauben.

Der Wrapper scannt definierte Filter in aufsteigender Reihenfolge durch Nutzung Ihrer <n> Zahl. Sobald ein Filter übereinstimmt, wird der Prozess an der Ausgabezeile anhalten.

Eine Zahl von Anwendungsbeispielen finden Sie unten:

wrapper.filter.trigger.<n>
Kompatibel :3.0.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Der Trigger kann jedwede Zeichenkette sein, und die folgende Eigenschaft ist für seine Konfiguration vonnöten.

Beispiel: 
wrapper.filter.trigger.1=Error
wrapper.filter.action.1=RESTART

Leerstellen in einem Trigger :

Die Zeichenkette, die gefiltert wird, kann Leerstellen enthalten. Aber aufgrund der Art, wie Konfigurationseigenschaften im Allgemeinen geladen werden, werden jedwede vorangehenden oder nachlaufenden Leerstellen entfernt, sobald die Eigenschaft geladen wurde.

Beispiel: 
wrapper.filter.trigger.1=  Restart me now.
wrapper.filter.action.1=RESTART

Wildcards:

Beginnend mit der Wrapper Version 3.5.5, ist es jetzt möglich, Wildcard/Platzhalter-Zeichen ('*' oder '?') in den Triggertext miteinzuschließen, wenn die wrapper.filter.allow_wildcards.<n> Eigenschaft auf TRUE gesetzt ist.

Gültige Wildcard-Zeichen sind:

  • Ein '*' Zeichen stimmt mit "0" (Null) oder mehr Zeichen überein.
  • Ein '?' Zeichen stimmt gensu nur mit einem Zeichen überein.

NOTE

Triggerwerte befinden sich irgendwo innerhalb einer Ausgabezeile, so dass es nicht notwendig ist, einen Wert mit einer "*" Wildcard voranzugehen oder nachzufolgen. Seien Sie sich bitte bewusst, dass dies tatsächlich die Geschwindigkeit des Loggings etwas reduziert, da es für den Musterabgleich schwieriger macht, festzustellen, dass ein vorgegebener Trigger NICHT in einer Zeile der Logausgabe gefunden wurde.

wrapper.filter.action.<n>
Kompatibel :3.0.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Die Definition einer Aktion erfordert, dass die folgende Eigenschaft konfiguriert wird. Wenn eine Aktion ausgelassen wird, führt dies standardmäßig zu einem NEUSTART.

Beispiel: 
wrapper.filter.trigger.1=Error
wrapper.filter.action.1=RESTART

Mögliche Aktionen sind:

  • DEBUG (Seit der Ver. 3.5.0) :

    bewirkt, dass eine Nachricht der Fehlersuche geloggt wird. Dies ist wirklich nur nützlich, verstehen zu helfen, wann die Aktion ausgelöst wurde.

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

  • DUMP (Seit Ver. 3.3.6) :

    erzeugt einen Thread-Dump.

  • GC (Garbage Collection) (Seit Ver. 3.5.7) :

    ruft eine vollständige Speicherbereinigung in der JVM auf. Seien Sie bewusst, dass, wenn Sie dies häufig tun, dies die Leistung der JVM beeinträchtigen kann, da eine vollständige Speicherbereinigung oft dazu führt, dass alle Threads für die Dauer der GC angehalten werden.

  • NEUSTART :

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

  • SHUTDOWN :

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

  • USER_<n> (Seit Ver. 3.5.0, Professional Edition) :

    bewirkt, dass ein benutzerdefiniertes Ereignis ausgelöst wird. Dies kann entweder das Aussenden einer Email, oder das Ausführen eines externen Systembefehls sein. Der Befehl könnte irgendetwas, vom Ausführen von Bereinigungsvorgängen bis zum Aufstellen von SNMP-Traps sein.

  • PAUSE (Seit Ver. 3.5.0) :

    hält dies die Java-Anwendung an, wenn das Pausieren aktiviert wurde und die JVM läuft. Sehen Sie bitte die wrapper.pausable Eigenschaft für mehr Details.

  • RESUME (Seit Ver. 3.5.0) :

    setzt die Java-Anwendung fort, wenn sich diese in einem angehaltenem Zustand befand. Dies könnte genutzt werden, wenn die JVM nicht beendet ist, wenn sie sich im angehaltenen Zustand befindet. Sehen Sie die wrapper.pausable Eigenschaft für Details.

  • SUCCESS (Seit Ver. 3.5.5) :

    informiert den Wrapper darüber, seinen internen Zählerstand für fehlgeschlagene Aufrufe zurückzusetzen und den gegenwärtigen Aufruf der JVM als "erfolgreich" zu bewerten. Dies kann in Anwendungen sinnvoll sein, die so entworfen wurden, in einer ziemlich kurzen Häufigkeit neu zu starten.

  • NONE :

    ist nützlich, weil es verhindert, dass jedwede Trigger mit einer höheren Zahl nicht ausgelöst werden.

Verketten mehrfacher Aktionen:

Beginnend von der Wrapper Version 3.5.0, ist es möglich, mehr als eine Aktion, durch Trennen dieser per Leerstelle oder Komma, zu spezifizieren. Wenn mehr als eine Aktion spezifiziert wurde, werden diese in schneller Abfolge in der festgelegten Reihenfolge ausgeführt.

Passend auf den Trigger wird das folgende Beispiel einen Thread-Dump erzeugen und dann die JVM neu starten.

Beispiel: 
wrapper.filter.trigger.1=Error
wrapper.filter.action.1=DUMP,RESTART

wrapper.filter.allow_wildcards.<n>
Kompatibel :3.5.5
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Wenn auf TRUE eingestellt, wird diese Eigenschaft den Wrapper darüber informieren, jedwede Wildcard-Platzhalterzeichen, die in der wrapper.filter.trigger.<n> für den Filter gefunden wurden, zu verarbeiten. Sehen Sie bitte: Ein Anwendungsbeispiel unten gibt mehr Informationen

Beispiel: 
wrapper.filter.allow_wildcards.1=TRUE

NOTE

Es ist nicht so schlecht, aber das Suchen nach einem Trigger, der eine Wildcard enthält, kann etwas mehr speicherintensiv sein. Dies trifft insbesondere auf lange Zeilenausgaben zu, wenn die Wildcards des Triggers sich mehr zu Beginn des Triggers befinden. Mehrfache Wildcards im gleichen Trigger verlangsamen auch die Dinge, da der Wrapper alle möglichen Kombinationen durchprobieren muss, um zu sehen, ob das Muster übereinstimmt.

wrapper.filter.message.<n>
Kompatibel :3.5.0
Editionen :Professional EditionStandard EditionCommunity Edition
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Die wrapper.filter.message.<n> Eigenschaft kann genutzt werden, um die Nachricht, die einem User angezeigt wird, wenn ein Trigger ausgelöst wird, zu überwachen. Dies kann sehr nützlich sein, um dem User zu erklären, was geschieht. Der Standardwert ist "Filter trigger matched."

Beispiel: 
wrapper.filter.trigger.1=java.lang.OutOfMemoryError
wrapper.filter.action.1=RESTART
wrapper.filter.message.1=The JVM has run out of memory.

Anwendungsbeispiel:

In diesem Abschnitt zeigen wir Ihnen einige Beispiele, wie Sie von Trigger Gebrauch machen können. Filter funktionieren, indem diese die Konsolenausgabe der JVM überwachen. Damit ein Trigger durch einen Fehler ausgelöst werden kann, muss die Java-Anwendung die Nachricht, die von der Konsole gefiltert wurde, ausgeben.

Einfache Übereinstimmung

In vielen Fällen möchten Sie ggf. eine Aktion als Antwort auf eine bestehende Nachricht in der Ausgabe Ihrer Anwendung auslösen.

In diesem Beispiel möchten wir bei allen Instanzen des Worts "Error" einen Trigger auslösen und das Neustarten der JVM veranlassen.

Beispiel: 
wrapper.filter.trigger.1=Error
wrapper.filter.action.1=RESTART
Beispiel Ausgabe des Wrappers: 
jvm 1    | The next line should cause the Wrapper to restart the JVM:
jvm 1    |   Error
wrapper  | Filter trigger matched.  Restarting JVM.
wrapper  | Launching a JVM...
jvm 2    | WrapperManager: Initializing...

Wildcards

In einigen Fällen kennen Sie nicht die genaue Zeichenkette, nach der Sie suchen, vergleichen möchten; dann ist es oft sehr nützlich, in der Lage zu sein, einen Trigger zu erstellen, der Wildcards enthält, die für den Abgleich genutzt werden können.

Beispiel: 
wrapper.filter.trigger.1=Head*Tail-?
wrapper.filter.allow_wildcards.1=TRUE
wrapper.filter.action.1=RESTART
Beispiel Wrapper-Ausgabe: 
jvm 1    | The next line should cause the Wrapper to restart the JVM:
jvm 1    |   Head a bunch of stuff, then Tail-1 and some more stuff.
wrapper  | Filter trigger matched.  Restarting JVM.
wrapper  | Launching a JVM...
jvm 2    | WrapperManager: Initializing...

Verketten von mehrfachen Aktionen

Beginnend mit der Wrapper Version 3.5.0, ist es möglich, mehr als eine Aktion, durch das Trennen mit Leerstellen oder Kommata, zu spezifizieren. Wenn mehr als eine Aktion spezifiziert wird, werden diese in schneller Abfolge in der angegebenen Reihenfolge ausgeführt.

Das folgende Beispiel führt einen Thread-Dump aus und startet dann die JVM in Antwort auf eine "Benutzerfehler"-Nachricht neu, die in der Konsolenausgabe entdeckt wurde.

Beispiel: 
wrapper.filter.trigger.1=User Error
wrapper.filter.action.1=DUMP,RESTART
Beispiel Ausgabe des Wrappers : 
jvm 1    | The next line should cause the Wrapper to restart the JVM:
jvm 1    |   User Error
wrapper  | Filter trigger matched.  Requesting thread dump.
wrapper  | Dumping JVM state.
wrapper  | Filter trigger matched.  Restarting JVM.
jvm 1    | Full thread dump Java HotSpot(TM) Client VM (1.5.0_24-149 mixed mode, sharing):
jvm 1    | 
jvm 1    | "WrapperSimpleAppMain" prio=5 tid=0x0100f400 nid=0x86c600 waiting on condition [0xb0e8e000..0xb0e8ed90]
jvm 1    | 	at java.lang.Thread.sleep(Native Method)
jvm 1    | ...
jvm 1    | "Exception Catcher Thread" prio=10 tid=0x01001910 nid=0x80ac00 runnable 
wrapper  | Launching a JVM...
jvm 2    | WrapperManager: Initializing...

Übereinstimmen mit Fehlern

In vielen Fällen werden Sie daran interessiert sein, eine Trigger basierend auf einem Textteil auszulösen, aber dann werden Sie ggf. feststellen, dass Sie diese in gewissen Situationen ignorieren möchten. Der Trigger wird in der Reihenfolge von "<n>" ausgeführt. Sobald eine Übereinstimmung gefunden wurde, werden alle anderen ignoriert. Dies ermöglicht es, dies so einzurichten, dass es auf Fehler abgleicht.

In diesem Beispiel möchten wir Aktionen bei allen Instanzen des Wortes "Error" auslösen und die JVM neu starten, außer wenn ein "IgnoreError" gefunden wurde.

Beispiel: 
wrapper.filter.trigger.1=IgnoreError
wrapper.filter.action.1=NONE
wrapper.filter.trigger.2=Error
wrapper.filter.action.2=RESTART
Beispiel Wrapper-Ausgabe: 
jvm 1    | The next line should be ignored:
jvm 1    |   IgnoreError
jvm 1    | 
jvm 1    | The next line should cause the Wrapper to restart the JVM:
jvm 1    |   Error
wrapper  | Filter trigger matched.  Restarting JVM.
wrapper  | Launching a JVM...
jvm 2    | WrapperManager: Initializing...

OutOfMemoryError Entdecken

NOTE

Ab der Wrapper Version 3.5.16, Update der Standardvorlage der Wrapper-Konfigurationsdatei wrapper.conf; so dass ein Neustart wegen einem zutreffenden OutOfMemoryError Filter nicht länger standardmäßig ausgelöst wird, wenn der User die -verbose:class Ausgabe aktiviert.

Wenn wir dies alles zusammen nehmen, können wir einen Filter erstellen, der entdeckt, wann immer ein OutOfMemoryErrorin einem Stack Trace gespeichert.

Der einfachste Weg ist Folgendes zu tun:

Beispiel: 
wrapper.filter.trigger.1=java.lang.OutOfMemoryError
wrapper.filter.action.1=RESTART

Dies kann das Problem als Ursache haben, dass wenn der Klassenname in einem anderen unerwarteten Ort angezeigt wird, ein unbeabsichtigter Neustart ausgelöst werden könnte. Ein Beispiel von diesem ist, wenn das -XX:+PrintClassHistogram Argument an die JVM weitergegeben wurde, wird Java ein sehr nützliches Flächenschaubild von allen geladenen Klassen, aufzeigen, wieviel Instanzen aktuell im Speicher geladen wurden. Wenn Java den Zählerstand für die OutOfMemoryError Klasse ausgibt, wird der oben genannte Trigger die JVM veranlassen, neuzustarten.

Beispiel: 
jvm 1    |  186:             6            384  sun.reflect.generics.repository.MethodRepository
jvm 1    |  187:             8            384  java.lang.OutOfMemoryError
wrapper  | The JVM has run out of memory.  Restarting JVM.
jvm 1    |  188:             8            384  java.io.OutputStreamWriter
jvm 1    |  189:             1            376  java.awt.Checkbox

Um ein Workaround dafür zu finden, ist es möglich Ausnahmen zu erstellen. Jedoch, wenn wir wissen, dass wir nur die OutOfMemoryError Klasse auslösen möchten, wenn diese in einem Stacktrace erscheint, dann können wir von Wildcards Gebrauch machen um ein passenderes Muster zu erzeugen.

Beispiel: 
wrapper.filter.trigger.1=Exception in thread "*" java.lang.OutOfMemoryError
wrapper.filter.allow_wildcards.1=TRUE
wrapper.filter.action.1=RESTART
wrapper.filter.message.1=The JVM has run out of memory.
Beispiel Wrapper Ausgabe: 
jvm 1    | Mention the java.lang.OutOfMemoryError exception (Not triggered)
jvm 1    | 
jvm 1    | Now thow a new java.lang.OutOfMemoryError to invoke a stack trace:
jvm 1    | Exception in thread "MyApp-Main" java.lang.OutOfMemoryError
wrapper  | The JVM has run out of memory.  Restarting JVM.
jvm 1    |      at com.myapp.Main.doSomething(Main.java:321)
jvm 1    |      at com.myapp.Main.main(Main.java:654)
wrapper  | Launching a JVM...
jvm 2    | WrapperManager: Initializing...

Es gibt immer noch einen Fall, in dem Sie jedoch ein falsches-positives erhalten. Wenn der User z.B. die komplette Wrapper-Konfigurationsdatei ausdruckt, dann sehen Sie eine Ausgabe wie die Folgende:

Beispiel Wrapper-Ausgabe: 
jvm 1    |   wrapper.filter.trigger.1=Exception in thread "*" java.lang.OutOfMemoryError
wrapper  | The JVM has run out of memory.  Restarting JVM.

Die ist natürlich nicht das, was Sie möchten. Sie können dies vermeiden, indem Sie einen einfachen Text-Abgleich auf den gleichen Text OHNE Aktivierung / Nutzung von Wildcards, so wie folgt, machen:

Beispiel: 
wrapper.filter.trigger.1=Exception in thread "*" java.lang.OutOfMemoryError
wrapper.filter.action.1=NONE

wrapper.filter.trigger.2=Exception in thread "*" java.lang.OutOfMemoryError
wrapper.filter.allow_wildcards.2=TRUE
wrapper.filter.action.2=RESTART
wrapper.filter.message.2=The JVM has run out of memory.