Windows Dienst Recovery Eigenschaften Übersicht

Der Java Service Wrapper erledigt einen sehr guten Job für das Überwachen und Wiederherstellung von Fehlern im Java-Prozess. Während der Wrapper selbst sehr stabil läuft, ist es gut, jedweden Schwachpunkt zu vermeiden. Der Wrapper ermöglicht es, von der Fähigkeit des Windows Dienste-Managers Gebrauch zu machen, um automatisch einen Dienst neu zu starten, der abgestürzt ist.

Die wrapper.ntservice.recovery.<n> Eigenschaften ermöglichen es, diese Wiederherstellungsfeatures innerhalb der Wrapper-Konfiguration zu konfigurieren. eine Beispielkonfiguration kann unten gefunden werden.

wrapper.ntservice.recovery.reset
Kompatibel :3.5.5
Editionen :Professional EditionStandard EditionCommunity Edition (Not Supported)
Betriebssysteme :WindowsMac OSX (Not Supported)Linux (Not Supported)IBM AIX (Not Supported)FreeBSD (Not Supported)HP-UX (Not Supported)Solaris (Not Supported)IBM z/OS (Not Supported)IBM z/Linux (Not Supported)

Der Windows Dienststeuerungsmanager pflegt einen Fehlerzähler für jeden installierten Dienst. Jedes Mal, wenn sich der Dienst unerwartet beendet, wird der Zähler hochgezählt und die registrierte Fehleraktion für diesen Zähler wird ausgelöst werden.

Diese Eigenschaft wird genutzt, um die fehlerfreie Zeit in Sekunden zu konfigurieren, nach der der Dienst-Manager diesen Zähler auf "0" (Null) zurücksetzen wird. Der Standardwert für diese Eigenschaft ist 3600 (= 1 Stunde). Falls "-1" gesetzt wurde, bedeutet dies, dass der Dienststeuerungsmanager niemals diesen Zähler zurücksetzen wird.

Beispiel, das Festlegen der Rücksetzzeit auf 86400 Sekunden (=1 Tag): 
wrapper.ntservice.recovery.reset=86400

NOTE

Um Verwirrung zu vermeiden, beachten Sie bitte, dass die Wiederherstellung-Registerseite im Eigenschaftendialogfenster der Systemsteuerung-Dienste die Rücksetzzeit eher in Tagen als in Sekunden angezeigt wird. Dies bedeutet, dass die angezeigten Werte auf Tage geplättet werden. Z.B. wird ein Wert von 3600 Sekunden (1 Stunde) als "0" (Null) Tage dargestellt wird.

wrapper.ntservice.recovery.command
Kompatibel :3.5.5
Editionen :Professional EditionStandard EditionCommunity Edition (Not Supported)
Betriebssysteme :WindowsMac OSX (Not Supported)Linux (Not Supported)IBM AIX (Not Supported)FreeBSD (Not Supported)HP-UX (Not Supported)Solaris (Not Supported)IBM z/OS (Not Supported)IBM z/Linux (Not Supported)

Eine Sache, die der Dienstmanager sie tun lässt, ist, einen externen Befehl als Antwort auf einen Fehler auszuführen. Dies kann genutzt werden, um Dinge wie eine Speicherreinigung oder das Versenden einer externen Benachrichtigung durchzuführen.

Während es möglich ist, eine unterschiedliche wrapper.ntservice.recovery.<n>.failure Eigenschaft für jedes Wiederherstellungsereignis zu spezifizieren, der Dienststeuerungsmanager API macht es nur möglich, einen einzelnen Befehl anzugeben, der dann als Fehleraktion auf ein oder mehrere Wiederherstellungsereignisse verwiesen werden kann.

Diese Eigenschaft hat keinen Standardwert und muß als eine oder mehrere "Fehleraktionen" spezifiziert werden. (wrapper.ntservice.recovery.<n>.failure property) ist auf COMMAND festgelegt.

Beispiel: 
wrapper.ntservice.recovery.command=C:\cleanup.bat

wrapper.ntservice.recovery.reboot_msg
Kompatibel :3.5.5
Editionen :Professional EditionStandard EditionCommunity Edition (Not Supported)
Betriebssysteme :WindowsMac OSX (Not Supported)Linux (Not Supported)IBM AIX (Not Supported)FreeBSD (Not Supported)HP-UX (Not Supported)Solaris (Not Supported)IBM z/OS (Not Supported)IBM z/Linux (Not Supported)

Wenn REBOOT für eine wrapper.ntservice.recovery.<n>.failure Eigenschaft festgelegt wurde, wird der Dienstkontrollmanager ein Systemereignis loggen, welches beschreibt, "warum das System neu gestartet wurde". Diese Eigenschaft wird genutzt, um den Nachrichtentext zu bestimmen.

Die Standardnachricht wird basierend auf der Sprache, die der Wrapper ausführt lokalisiert. Für Deutsch, ist der Standard: "Das System wird aufgrund eines unerwarteten Fehlers im Wrapper-Dienst neugestartet."

Beispiel: 
wrapper.ntservice.recovery.reboot_msg=System will reboot now.

wrapper.ntservice.recovery.<n>.failure
Kompatibel :3.5.5
Editionen :Professional EditionStandard EditionCommunity Edition (Not Supported)
Betriebssysteme :WindowsMac OSX (Not Supported)Linux (Not Supported)IBM AIX (Not Supported)FreeBSD (Not Supported)HP-UX (Not Supported)Solaris (Not Supported)IBM z/OS (Not Supported)IBM z/Linux (Not Supported)

Diese Eigenschaft setzt die Fehleraktion, die stattfinden soll, wenn der Wrapper abstürzt. Die "<n>" Komponente des Eigenschaftennamen gibt die Zahl des Fehlerzählers an.

Der Dienstkontrollmanager zählt die Male, die jeder Dienst seit dem Systemstart fehlschlug. Der Zähler wird auf "0" (Null) zurückgesetzt, wenn der Dienst für zumindest wrapper.ntservice.recovery.reset Sekunden nicht fehlschlug. Wenn der Dienst fehlschlägt, wird der Fehlerzähler (N) genutzt, um zu entscheiden, welche Fehleraktion unternommen werden soll. Diese Aktionen werden mit der wrapper.ntservice.recovery.<n>.failure Eigenschaft definiert, wobei'N' der Fehlerzähler ist. Wenn N größer als die letzte konfigurierte Aktion ist, dann wird die Fehleraktion mit der höchsten N (<n> index) genutzt werden.

Mögliche Aktionen sind:

  • NONE :

    Der Dienst-Manager tut nichts. Dies ist das Gleiche als ob keine Wiederherstellung-Eigenschaften spezifiziert worden wären. Der Dienst wird beendet und bleibt im Zustand beendet. Jedwede Fehleraktionen, die mit höheren N-Werten definiert wurden, werden nie erreicht werden.

  • RESTART :

    Der Dienst-Manager startet den Dienst neu.

  • COMMAND :

    Der Dienst-Manager führt den spezifizierten Befehl mit der wrapper.ntservice.recovery.command Eigenschaft aus. Wenn Sie wünschen, dass der Dienst nach Ausführung des Befehls neu gestartet werden soll, dann muss innerhalb des Befehls getan werden.

  • REBOOT :

    Der Dienst-Manager wird die Maschine neu starten. Wenn der Startmodus des Dienstes auf AUTO_START festgelegt wurde, dann wird der Dienst nach dem Neustart neu gestartet. Sehen Sie für mehr Information bitte die wrapper.ntservice.starttype-Eigenschaft.

Beispiel: 
wrapper.ntservice.recovery.1.failure=RESTART
wrapper.ntservice.recovery.2.failure=COMMAND
wrapper.ntservice.recovery.3.failure=REBOOT

Während die API es ermöglicht, eine Fehleraktion nach NONE oder REBOOT zu spezifizieren, werden sie niemals genutzt werden.

NOTE

Die Wiederherstellung-Registerseite im Eigenschaftendialog in Systemsteuerung-Dienste([Systemsteuerung] - [Administrator Tools] - [Dienste]) zeigt nur die 3 zuerst konfigurierten Fehleraktionen. Die API ermöglicht es jedoch, mehr zu definieren. Seien Sie sich bitte bewusst, dass das Nutzen von mehr als 3 Fehleraktionen auf einen User, der das Dialogfenster sieht, verwirrend erscheinen kann.

wrapper.ntservice.recovery.<n>.delay
Kompatibel :3.5.5
Editionen :Professional EditionStandard EditionCommunity Edition (Not Supported)
Betriebssysteme :WindowsMac OSX (Not Supported)Linux (Not Supported)IBM AIX (Not Supported)FreeBSD (Not Supported)HP-UX (Not Supported)Solaris (Not Supported)IBM z/OS (Not Supported)IBM z/Linux (Not Supported)

Diese Eigenschaft stellt die Zeit in Sekunden ein, die der Dienstkontrollmanager warten wird bis er eigentlich die entsprechende Aktion, die in wrapper.ntservice.recovery.<n>.failure spezifiziert ist, durchführt.

Der Wert dieser Eigenschaft kann nicht kleiner als "0" (Null) sein. Der Standardwert ist 3 Mal der Wert der wrapper.ping.timeout Eigenschaft.

Während es in der Theorie möglich ist, eine Verzögerung für die Fehleraktion "NONE" einzustellen, wird der Dienstkontrollmanager die Verzögerung in diesem Fall ignorieren.

Beispiel, Festlegen der Verzögerung auf 90 Sekunden (1 1/2 Min.): 
wrapper.ntservice.recovery.1.delay=90

NOTE

Um beim Prüfen des Dienstes im Dienstdialog auf der Wiederherstellung-Registerseite Verwirrung zu vermeiden, nehmen Sie bitte zur Kenntnis, dass die Verzögerungszeit in Minuten angezeigt wird. Dies bedeutet, dass die angezeigten Werte auf Minuten geplättet werden. Z.B. wird ein Wert von 90 Sekunden (1.5 min) als 1 Minute angezeigt werden.

Zusammenfassung

Das folgende Beispiel

  • setzt die Rücksetzzeit auf 86400 Sekunden (1 Tag) fest
  • 1ster Fehler : sagt den Dienstkontrollmanager 90 Sekunden (1 1/2 Min.) zu warten bevor Ausführung von Fehleraktion 1
  • 1ster Fehler: Festlegen der Fehleraktion 1 auf RESTART, was den Dienst neu starten wird.
  • 2ter Fehler: sagt den Dienstkontrollmanager 180 Sekunden (3 Min.) zu warten bevor Ausführung von Fehleraktion 2
  • 2ter Fehler : Festlegen der Fehleraktion 2 auf COMMAND, was einen externen Befehl ausführen wird
  • 2ter Fehler : Festlegen des externen Befehls auf "C:\cleanup.bat"
  • 3ter Fehler: sagt den Dienstkontrollmanager 600 Sekunden (10 Min.) zu warten bevor Ausführung von Fehleraktion 3
  • 3ter Fehler: Festlegen der Fehleraktion 3 auf REBOOT, was zum Neustart der Maschine führt
  • 3rd Failure: Festlegen der Nachricht, die durch den Neustart im System-Ereignislog mit "System will reboot now." geloggt wird.
Beispiel: 
wrapper.ntservice.recovery.reset=86400

wrapper.ntservice.recovery.1.delay=90
wrapper.ntservice.recovery.1.failure=RESTART

wrapper.ntservice.recovery.2.delay=180
wrapper.ntservice.recovery.2.failure=COMMAND
wrapper.ntservice.recovery.command=C:\cleanup.bat

wrapper.ntservice.recovery.3.delay=600
wrapper.ntservice.recovery.3.failure=REBOOT
wrapper.ntservice.recovery.reboot_msg=System will reboot now.

Prüfen auf der Wiederherstellen-Registerseite des Windows Dienstes:

Startup-Restart: Verzögerung
  • wrapper.restart.delay (2.2.9)

    Regelt die Zahl Sekunden, die zwischen dem Beenden einer JVM und dem Starten einer neuen JVM gewartet wird.

  • wrapper.startup.delay (3.1.0)

    Steuert die Anzahl Sekunden Wartezeit zwischen dem Zeitpunkt, wann der Wrapper gestartet wird und die erste JVM gestartet wurde.

  • wrapper.startup.delay.console (3.1.0)

    Überschreibt wrapper.startup.delay, wenn diese als eine Konsolenanwendung ausgeführt wird.

  • wrapper.startup.delay.service (3.1.0)

    Überschreibt wrapper.startup.delay, wenn diese als ein Dienst ausgeführt wird.

  • wrapper.request_thread_dump_on_failed_jvm_exit.delay (3.5.6)

    Konfiguriert die Anzahl Sekunden, die der Thread-Dump Zeit hat, um sich zu beenden, bevor der JVM-Prozess zwangsweise beendet wird.

  • wrapper.ntservice.recovery.<n>.delay (3.5.5) ( Std/Pro )

    Konfiguriert die maximale Sekundenanzahl, die der Dienst-Control-Manager wartet, bevor nach <n> Fehlern eine Aktion durchgeführt wird.

  • wrapper.jvm_kill.delay (3.5.6) ( Pro )

    Konfiguriert die Anzahl Sekunden Pause, die zwischen dem Abfeuern eines JVM-kill-Ereignisses und dem tatsächlichen Beenden liegt.