World Map
Java Service Wrapper ist der einfachste Weg, um Ihr Produkt zuverlässiger, sicherer zu machen.
  • Free Trial
  • Buy Now
wrapper.jvm_kill.delay Eigenschaft

wrapper.jvm_kill.delay

Kompatibel :3.5.6
Editionen :Professional EditionStandard Edition (Not Supported)Community Edition (Not Supported)
Betriebssysteme :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

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.

Beispiel:
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.

Unix-Beispiel:
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.

Windows-Beispiel:
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

Startup-Restart: Verzögerung