• wrapper.ping.timeout Eigenschaft
• wrapper.ping.timeout.action Eigenschaft

Kompatibel :	1.0.0
Editionen :
Betriebssysteme :

Erlaubte Sekundenzahldauer zwischen zwei Ping-Antworten von der JVM ausgehend.

Der Standardwert ist "30 Sekunden".

wrapper.ping.timeout=30

Das Festlegen dieses Eigenschaftenwerts auf "0" (Null) bedeutet, dass es niemals einen Time-out geben wird. Der Ping-Time-out muss wenigstens 5 Sekunden länger als der Wert von wrapper.ping.interval sein. Der Wrapper verändert, wenn notwendig, den Wert zur Laufzeit, um Probleme zu vermeiden.

In normalen Betrieb pingt der Wrapper die JVM einmal alle 5 Sekunden, um sicherzustellen, dass sein Prozess nicht "eingefroren" ist. Der Ping-Time-out ist die Zeitdauer, die für 2 Antworten von der JVM gegeben wird, bevor der Wrapper annimmt, dass diese "aufgehängt" ist und sie neu startet.

Diese Eigenschaft kontrolliert auch die Zeitdauer, die der JVM gegeben wird, ohne dass sie seitens des Wrappers gepingt wird. Wenn der Wrapper die JVM für länger als die angegebene Time-out-Zeit nicht anpingt, wird diese beendet, indem sie den Wrapper erlaubt, sich durch das Starten einer JVM neu zu synchronisieren. Dies stellt auch sicher, dass die JVM sich beenden wird, wenn der Wrapper-Prozess auf abnormale Weise beendet wurde. (Durch das zwangsweise Beenden des Wrapper-Prozesses im Windows Task Manager, oder durch Nutzung des Befehls "kill -9" Signals auf UNIX-Systemen.)

Mit dem Hinzufügen der wrapper.cpu.timeout Eigenschaft, gibt es jetzt fast keinen Grund, warum Sie diese Eigenschaft jemals ändern sollten. Die einzigen Gründen, warum Sie Ping-Timeouts bekommen sollten, sind wenn das System unter hoher Last steht oder wenn die JVM wirklich hängt. Die CPU-Timeout sollte jetzt jegliche Probleme erkennen, die Sie mit der CPU haben.

Kompatibel :	3.5.16
Editionen :
Betriebssysteme :

Diese Eigenschaft erlaubt, eine bestimmte Aktion zu definieren, die ausgeführt wird, wann immer ein Ping-Timeout nach der Anzahl an Sekunden, die in wrapper.ping.timeout Eigenschaft oben definiert wurden, stattfindet.

Aus Gründen der Konsistenz und der Rückwärtskompatibilität ist die definierte Standardaktion RESTART.

wrapper.ping.timeout.action=RESTART

Mögliche Aktionen sind:

• DEBUG (Seit Ver. 3.5.0) :

  sorgt dafür, dass eine Debug-Nachricht geloggt wird. Dies ist wirklich nur nützlich, um besser zu verstehen, wann die Aktion gestartet 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 (Seit Ver. 3.3.6) :

  wird ein Thread-Dump aufgerufen.

• GC (Seit Ver. 3.5.7) :

  wird ein vollständiger Speicherreinigungsvorgang (GC) in der JVM aufgerufen. Seien Sie sich bitte bewusst, dass das häufige Ausführen dieses Vorgangs das Leistungsvermögen der JVM beeinträchtigen kamnn, da eine vollständige Reinigung oft bewirkt, dass alle Threads für die Dauer der GC blockiert werden.

• RESTART :

  beendet die gegenwärtige JVM und startet dann einen neuen Aufruf.

• SHUTDOWN :

  beendet die JVM wie auch den Wrapper.

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

  bewirkt dies, dass ein benutzerdefiniertes Ereignis gestartet wird. Dies kann entweder das Versenden einer Email, oder die Ausführung eines externen Systembefehls sein. Der Befehl könnte alles Mögliche sein, vom Ausführen eines Reinigungsvorgangs bis zur Bereitstellung eines SNMP-Traps.

• PAUSE (Seit Ver. 3.5.0) :

  unterbricht die Java-Anwendung, wenn das Pausieren aktiviert ist und die JVM läuft. Sehen Sie die wrapper.pausable Eigenschaft für mehr Details.

• RESUME (Seit Ver. 3.5.0) :

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

• SUCCESS (Seit Ver. 3.5.5) :

  sagt es dem Wrapper, seinen internen Zähler über Aufruffehler zurücksetzen und den aktuellen JVM-Aufruf als "erfolgreich"zu zählen. Dies kann in Anwendungen nützlich sein, die entworfen wurden, in ziemlich kurzen Zeitabständen neu zu starten.

• NONE :

  ist nützlich, weil es verhindert, dass alle Trigger mit einer höheren Zahl ausgeführt werden.

Verketten von mehrfachen Aktionen:

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

Das folgende Beispiel versucht, einen Thread-Dump auszuführen und dann die JVM neuzustarten . Der Thread-Dump erfolgt nur, wenn die JVM nicht vollständig "eingefroren" ist.

wrapper.ping.timeout.action=DUMP,RESTART

• wrapper.ping.alert.loglevel (3.5.16)

  Steuert auf welcher Protokollierungsstufe die ping-Warnmeldungen geloggt werden.

• wrapper.ping.alert.threshold (3.5.16)

  Gibt eine Warnung aus, wann immer eine Ping-Antwort länger als die angegebene Anzahl an Sekunden dauert.

• wrapper.ping.interval (3.0.5)

  Konfiguriert die Anzahl an Sekunden zwischen zwei Ping-Anfragen an die JVM.

• wrapper.ping.interval.logged (3.2.4)

  Konfiguriert die Anzahl an Sekunden zwischen zwei Ping-Anfragen, die geloggt werden sollen.

• wrapper.ping.timeout (1.0.0)

  Konfiguriert die erlaubte Anzahl an Sekunden, die zwischen zwei Ping-Antworten, ausgehend von der JVM, liegen dürfen.

• wrapper.ping.timeout.action (3.5.16)

  Konfiguriert die auszuführenden Aktionen, wann immer die Ping-Timeoutzeit abgelaufen ist.

• wrapper.cpu.timeout (2.2.8)

  Konfiguriert die Anzahl an Sekunden ohne Prozessorkontakt, bevor die JVM eine Warnung versendet und Timeoutzeiten verlängert.

• wrapper.max_hostid_timeout (3.4.0) ( Std/Pro )

• wrapper.logfile.close.timeout (3.5.21)

  Regelt die Anzahl an Sekunden nach den die Log-Datei nach dem letzten Logeintrag geschlossen werden soll.

• wrapper.logfile.flush.timeout (3.5.21)

  Konfiguriert das Zeitintervall in Sekunden, nach dem der Wrapper alle Ausgaben in die Logdatei ausgibt.

• wrapper.logfile.inactivity.timeout (3.2.0, obsolet ab der 3.5.21)

  Regelt die Anzahl an Sekunden nach den die Log-Datei nach dem letzten Logeintrag geschlossen werden soll.

• wrapper.ping.timeout (1.0.0)

  Konfiguriert die erlaubte Anzahl an Sekunden, die zwischen zwei Ping-Antworten, ausgehend von der JVM, liegen dürfen.

• wrapper.startup_thread.timeout (3.5.11)

  Konfiguriert die Zahl Sekunden, die gewährt werden, damit sich die asynchronen Startvorgänge vollständig beenden können.

• wrapper.startup.timeout (1.0.0)

  Konfiguriert die Anzahl an Sekunden, die zwischen dem Starten der JVM seitens des Wrappers und der Zeit, die die JVM braucht, zu antworten, dass die Anwendung gestartet wurde, liegt.

• wrapper.shutdown.timeout (2.2.7)

  Konfiguriert die Anzahl Sekunden, die man Zeit hat, zwischen der Zeit, wenn der Wrapper die JVM auffordert, sich zu beenden und der Zeit, wenn die JVM antwortet, dass sie sich beendet hat.

• wrapper.jvm_exit.timeout (2.2.8)

  Konfiguriert die Anzahl der gewährten Sekunden zwischen der Zeit, wenn die JVM berichtet, dass sie beendet wurde und der Zeit, wann der JVM-Prozess sich tatsächlich beendet.

• wrapper.jvm_cleanup.timeout (3.4.0)

  Konfiguriert die Anzahl der für den Wrapper gewährten Sekunden, um die Child-Prozesse nach dem Beenden der JVM aufzuräumen.

• wrapper.jvm_terminate.timeout (3.5.18)

  Konfiguriert die Anzahl der Sekunden, die vergehen darf zwischen dem Zeitpunkt an dem der Wrapper ein erzwungenes Beenden der JVM beim System anfragt, bis zu dem Zeitpunkt an dem er bestätigt, dass der Prozess tatsächlich beendet wurde.

• wrapper.event.<event_name>.command.block.timeout (3.3.0) ( Pro )

  Konfiguriert wie lange der Wrapper für die Beendigung eines konfigurierten Ereignisses warten wird.

• wrapper.event.<event_name>.email.receive.timeout (3.3.2) ( Pro )
• wrapper.event.<event_name>.email.send.timeout (3.3.2) ( Pro )