Kompatibel :	3.5.6
Editionen :
Betriebssysteme :

Diese Eigenschaft steuert die Anzahl Sekunden an Pause zwischen dem Starten des jvm_kill Ereignisses , und dem tatsächlichen zwangsweise Beenden der JVM.

Der Standardwert ist "0" (Null ) Sekunden.

wrapper.jvm_kill.delay=0

Wenn sich der Wrapper entscheidet, die JVM zwangsweise zu beenden, werden einige Anwendungen, zuerst ein externen Befehl ausführen wollen, um etwas mit der JVM zu tun, bevor diese zwangsweise beendet wird. Dies wird durch Nutzen folgender Eigenschaft und Ereignisses erreicht: one of "event command" (wrapper.event.<event_name>.command.argv.<n>) Eigenschaft und des jvm_kill Ereignisses. Solange es möglich ist, die Eigenschaft wrapper.event.<event_name>.command.block zu setzen, vergewissern Sie sich bitte, dass - bevor Sie fortfahren - der Befehl komplett durchläuft; einige Anwendungen könnten immer noch Timing-Probleme haben, die zusätzliche Zeit benötigen.

Der Wrapper kann so konfiguriert worden sein, dass er einen Thread-Dump anfordert, bevor die JVM zwangsweise durch die interne Eigenschaft wrapper.request_thread_dump_on_failed_jvm_exit beendet würde. Jedoch kann dies - als ein Beispiel - auch durch das Ausführen eines Befehls in Antwort auf ein jvm_kill Ereignis erledigt werden.

Unix:

Unter UNIX kann ein Thread-Dump auch durch Versenden eines SIGQUIT Signals an den JVM-Prozess ausgeführt werden. Das jvm_kill Ereignis erfolgt sofort, bevor der JVM-Prozess zwangsweise beendet wird. Dies bedeutet, dass die JVM zum Zeitpunkt, wenn das Signal tatsächlich ausgesendet wird, wahrscheinlich bereits beendet wurde. Um ein Workaround für dieses Timing-Problem zu haben, fügen wir eine 5 Sekunden dauernde Verzögerung zwischen der Ausführung des externen Befehls und dem tatsächlichen Beenden der JVM durch den Wrapper hinzu.

wrapper.jvm_kill.delay=5
wrapper.event.jvm_kill.command.loglevel=INFO
wrapper.event.jvm_kill.command.argv.1=kill
wrapper.event.jvm_kill.command.argv.2=-SIGQUIT
wrapper.event.jvm_kill.command.argv.3=%WRAPPER_EVENT_JVM_PID%

Windows:

Dies könnte auch unter Windows erledigt werden, indem es als ein Dienst laufen würde. Das folgende Beispiel setzt voraus, dass der Dienst als "MyApp" bezeichnet wurde . Die "255" muß dem Wert der wrapper.thread_dump_control_code Eigenschaft entsprechen.

wrapper.jvm_kill.delay=5
wrapper.event.jvm_kill.command.loglevel=INFO
wrapper.event.jvm_kill.command.argv.1=sc
wrapper.event.jvm_kill.command.argv.2=control
wrapper.event.jvm_kill.command.argv.3="MyApp"
wrapper.event.jvm_kill.command.argv.4=255

• 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.