Übersicht Ereignisse
Kompatibel :3.3.0
Editionen :Professional EditionStandard Edition (Not Supported)Community Edition (Not Supported)
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

Der Java Service Wrapper verfügt über die Möglichkeit, einen Systemadministrator per Email zu benachrichtigen, sowie auch auf eine breite Anzahl von integrierten, benutzerdefinierten Ereignissen zu reagieren.

Eigenschaften der Ereigniskonfiguration

Dieser Abschnitt beinhaltet eine vollständige Liste von Eigenschaften, die genutzt werden können, um zu konfigurieren und zu steuern, wie der Wrapper auf Ereignisse reagiert.

Allgemeine Ereigniseigenschaften:

Ereignisemail-Eigenschaften:

Ereignisbefehl-Eigenschaften:

Ereignistypen

Der Wrapper ist in der Lage, Emails zu versenden und/oder externe Befehle auszuführen in Antwort auf eine Anzahl von Ereignissen. Die folgende Liste beschreibt jedes dieser definierten Ereignisse:

  • wrapper_start :

    Wird ausgelöst, wenn der Wrapper-Prozess zuerst gestartet wird. Dieses Ereignis kann genutzt werden, um x-beliebige Initialisierungsarbeiten zu erledigen, die getan werden müssen, bevor die JVM das erste Mal gestartet wird.

    Im Falle von Emails kann es genutzt werden, um anzuzeigen, dass das System z.B. gerade neu gestartet wurde.

  • jvm_prelaunch :

    Wird ausgelöst, wann immer eine neue JVM gestartet werden soll. Dieses Ereignis kann genutzt werden, um x-beliebige Initialisierungsarbeiten zu erledigen, die getan werden müssen, bevor jede JVM gestartet wird.

  • jvm_start :

    Wird sofort ausgelöst, nachdem eine neue JVM gestartet wurde, aber bevor Ihre Anwendung gestartet wurde.

  • jvm_started :

    Wird ausgelöst, sobald der Wrapper-Code in der JVM den Wrapper-Prozess darüber informiert hat, dass die neue Anwendung betriebsbereit läuft.

    Bitte beachten Sie, dass außer wenn die Integrationsmethode 3 (WrapperListener) genutzt wird, dies ausgelöst werden kann, bevor die Benutzeranwendung komplett hochgestartet wurde. Abhängig von der Benutzeranwendung, beides Methode 1 (WrapperSimpleApp) und Methode 2 (WrapperStartStopApp) können auch so konfiguriert werden, dass diese warten bis die Anwendung komplett gestartet wurde, bevor diese melden, dass diese betriebsbereit ist. Sehen Sie bitte im Abschnitt "Erweitert" jeder Integrationsmethode für mehr Details.

  • jvm_deadlock (Since ver. 3.5.0) :

    Wird ausgelöst, wann immer ein Thread-Deadlock mittels des Check Deadlock-Features innerhalb der JVM entdeckt wurde.

  • jvm_stop :

    Wird ausgelöst, wann immer eine JVM im Prozess ist, sich zu beenden. Das Ereignis wird ausgelöst, wenn die JVM abstürzt, aber sie wird erfolgen, nachdem der JVM-Prozess sich beendet hat. Wenn das System abstürzt oder aus irgendwelchen Gründen Strom verliert, wird das Ereignis niemals ausgelöst werden.

  • jvm_stopped :

    Wird ausgelöst, nachdem eine JVM aus irgendwelchen Gründen beendet wurde. Dieses Ereignis kann genutzt werden, um Speicherbereinigungsarbeiten durchzuführen. . Wenn das System abstürzt oder aus irgendwelchen Gründen Strom verliert, wird das Ereignis niemals ausgelöst werden.

  • jvm_restart :

    Wird ausgelöst, wenn der Wrapper dabei ist, eine JVM neuzustarten.

  • jvm_failed_invocation :

    Wird ausgelöst, wenn die JVM sich in einem Zustand beendet hat, der zu einem Neustart führt, aber die totale Zeit, die die JVM lief, geringer als die in der Eigenschaft wrapper.successful_invocation_time konfigurierte Zeit war.

  • jvm_max_failed_invocations :

    Wird ausgelöst, wenn die JVM sich in einem Zustand beendet hat, der zu einem Neustart führt, die fehlgeschlagenen Aufrufe der (jvm_failed_invocation event) werden hochgezählt, die Gesamtzahl der aufeinanderfolgenden fehlgeschlagenen Aufrufe ist größer als die in der konfigurierten Eigenschaft wrapper.max_failed_invocations genannten.

  • jvm_kill:

    Wird ausgelöst, wenn der Wrapper entschied, dass eine JVM, von der geglaubt wird, dass sie "eingefroren" ist, zwangsweise beendet werden muss. Dies passiert, bevor der JVM-Prozess zwangsweise beendet wird. Diesem Ereignis geht stets das jvm_stop-Ereignis voraus und wird gefolgt von den jvm_killed und jvm_stopped-Ereignissen. Sehen Sie bitte die wrapper.jvm_kill.delay-Eigenschaft, wenn beim Ausführen von Befehlen für dieses Ereignis eine Verzögerung gebraucht wird.

  • jvm_killed :

    Wird ausgelöst, wenn der Wrapper eine JVM zwangsweise beendet hat, von der geglaubt wurde, dass sie "eingefroren" sei. Dieses Ereignis wird stets von einem jvm_stopped-Ereignis gefolgt werden.

  • jvm_unexpected_exit :

    Wird ausgelöst, wenn der JVM-Prozess aus einem unerwarteten Grund verschwindet. Zum beispiel, wenn dieser abstürzt. Dieses Ereignis wird stets von den jvm_stop und jvm_stopped-Ereignissen gefolgt werden.

  • wrapper_stop :

    wir zuletzt ausgelöst werden, wenn der Wrapper-Prozess sich beendet. Dieses Ereignis kann genutzt werden, um Speicherbereinigungsarbeiten durchzuführen, die getan werden müssen, wenn die letzte JVM beendet wurde.

    Beachten Sie bitte, dass dieses Ereignis nur ausgelöst wird, wenn der Wrapper sich normal beendet. Wenn das System abstürzt oder aus irgendwelchen Gründen Strom verliert, wird das Ereignis niemals ausgelöst werden.

  • wrapper_pause (Seit der Ver. 3.5.0):

    Wird ausgelöst, wenn der Wrapper sich im angehaltenen Zustand befindet. Abhängig von der Konfiguration, wie sich der Wrapper in diesem Zustand verhält, werden Ereignisse bezüglich der JVM beendet oder ausgelöst.

    Sehen Sie für mehr Details die wrapper.pausable und wrapper.pausable.stop_jvm Eigenschaften.

  • wrapper_resume (Seit Ver. 3.5.0) :

    Wird ausgelöst, wenn der Wrapper fortgesetzt wird. Abhängig von der Konfiguration, wie der Wrapper sich im gehaltenen Zustand verhält, werden auch Ereignisse bezüglich der gestarteten JVM ausgelöst werden.

    Sehen Sie für mehr Details die wrapper.pausable und wrapper.pausable.stop_jvm Eigenschaften.

  • user_<n> (Seit Ver. 3.5.0):

    Benutzereignis, welches in Antwort auf eine Aktion ausgelöst wird. Die '<n>'- Komponente des Ereignisnamens ist eine x-beliebige ganzzahlige Integerzahl im Bereich zwischen 1 und 32767.

    Aktionen, die konfiguriert werden können, um ein Benutzereignis auszulösen, beinhalten: wrapper.filter.action.<n>, wrapper.timer.<n>.action, wrapper.check.deadlock.action, and wrapper.event.<event_name>.command.block.action.

Ereignismails

NOTE

Diese Funktion setzt die Professional Edition des Java Service Wrappers voraus.

Der Wrapper ist in der Lage, Warnmeldungen in Antwort auf gewisse Ereignisse zu versenden. Emails können mit einer massgeschneiderten Nachricht, zusammen mit einem Teil der Wrapper-Logdatei, versendet werden. Dies ermöglicht es einem Systemadministrator zu entscheiden, ob es notwendig ist, weitere Aktionen zu unternehmen oder nicht. Sehen Sie bitte die Dokumentation der individuellen Eigenschaften für Details bezüglich ihrer Nutzung.

Beispiel(Send einer Email in Antwort auf Neustarts der JVM): 
# Allgemeine Ereignisemail-Eigenschaften.
#wrapper.event.default.email.debug=TRUE
wrapper.event.default.email.smtp.host=smtp.mycompany.com
wrapper.event.default.email.smtp.port=25
wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%] Event Notification
wrapper.event.default.email.sender=myapp-noreply@mycompany.com
wrapper.event.default.email.recipient=myapp-admin@mycompany.com

# Ereignisspezifische Einstellungen.
wrapper.event.jvm_restart.email=TRUE
wrapper.event.jvm_restart.email.body=Die JVM wurde neue gestartet.\n\nBitte überprüfen Sie ihren Status.\n

Die Eigenschaften sind alle von der Form wrapper.event.<x>.email* wobei die <x>-Komponente entweder dem Schlüsselwort default, oder einer der oben definierten Ereignistypen.

Wann immer eine Eigenschaft nicht ausdrücklich für einer dieser Ereignisnamen definiert wurde, wird der Standard-Wert wrapper.event.default.email* genutzt werden. Dies ist nützlich für das Einstellen von Werten, die für alle Ereignisemails allgemein verbreitet sind.

Ereignisbefehle

NOTE

Diese Funktion erfordert die Professional Edition des Java Service Wrappers.

Der Wrapper ist in der Lage, externe Befehle als Antwort auf gewisse Ereignisse auszuführen. Dies kann nützlich sein, um Systemspeicherbereinigungsarbeiten durchzuzführen, Benachrichtigungen zu versenden oder um Aktionen zu unternehmen, die nur nativ selbst bearbeitet werden können. Sehen Sie die Dokumentation der individuellen Eigenschaften bezüglich Details ihrer Nutzung.

Es ist möglich, den Java Service Wrapper anzuweisen, den Befehl zu starten und dann diesen zu "vergessen" , zu blockieren bis der Befehl beendet wurde, oder eine Höchstzeit zu warten, damit der befehl sich beenden kann. Wenn das Warten einen Time-out erfährt, dann wird der Befehl im Ausführen belassen.

Der Wrapper bietet aktuell keine Möglichkeit an, die Ausgabe von externen Befehlen zu loggen.

Beispiel (Ausführen von 'mycleanup', bevor die JVM gestartet wird; keine Wartezeit): 
wrapper.event.jvm_prelaunch.command.argv.1=/usr/bin/mycleanup
wrapper.event.jvm_prelaunch.command.argv.2=parameter1
Beispiel (Ausführen von 'mycleanup', bevor die JVM gestartet wird; unendliche Wartezeit): 
wrapper.event.jvm_prelaunch.command.argv.1=/usr/bin/mycleanup
wrapper.event.jvm_prelaunch.command.argv.2=parameter1
wrapper.event.jvm_prelaunch.command.block=TRUE
Beispiel (Ausführen von 'mycleanup', bevor die JVM gestartet wird; 5 Sekunden Wartezeit): 
wrapper.event.jvm_prelaunch.command.argv.1=/usr/bin/mycleanup
wrapper.event.jvm_prelaunch.command.argv.2=parameter1
wrapper.event.jvm_prelaunch.command.block=TRUE
wrapper.event.jvm_prelaunch.command.block.timeout=5

Die Eigenschaften sind alle von der Form wrapper.event.<x>.command.*, wobei die <x>-Komponente einer der oben definierten Ereignistypen ist.

Wann immer eine Eigenschaft nicht ausdrücklich für eine der Ereignisnamen definiert wurde, dann wird vom Standard-Wert wrapper.event.default.command.* Gebrauch macht. Dies ist nützlich für das Festlegen von Werten, die für alle Ereignisbefehle allgemein verbreitet sind.