Kompatibel :	3.3.6
Editionen :
Betriebssysteme :

Der Wrapper hat mehrere Features, die konzipiert wurden, um herauszufinden, wann eine JVM abgestürzt ist oder auf andere Weise instabil wurde. Normalerweise sollte alles aktiviert gelassen werden. Wenn jedoch eine JVM mit einem Debugger verbunden ist, kann es sein, dass die JVM aus gutem Grund abgestürzt erscheint, da gleichzeitig viele verschiedene Fehlersuchvorgänge stattfinden. In diesen Fällen würde der Wrapper normalerweise denken, dass die JVM abgestürzt wäre, und diese zwangsweise inmitten eines Fehlersuchvorgangs beenden und neu starten. Der Wrapper hat einen Workaround für dieses Problem, indem er die konfigurierte Java-Befehlszeile überprüft und gewisse Timeouts ignoriert, wenn dieser entdecken würde, dass ein Debugger im Einsatz ist. Diese Eigenschaft ermöglicht es, diesen Fehlersuchen-Check zu aktivieren oder zu deaktivieren. Der Standardwert ist "TRUE", wobei Fehlersuchvorgänge erkannt und gewisse Time-outs ignoriert werden.

wrapper.java.detect_debug_jvm=TRUE

Entdecken des Debuggers:

Der Wrapper entscheidet, dass die JVM einen Debugger nutzt, wenn die wrapper.java.command Eigenschaft auf "jdb" oder "jdb.exe" gesetzt ist oder wenn eine der wrapper.java.additional.<n> Eigenschaften auf "-Xdebug" gesetzt wird.

Wenn der Wrapper entdeckt, dass ein Debugger genutzt wird, wird der folgende Banner beim Starten geloggt:

------------------------------------------------------------------------
The JVM is being launched with a debugger enabled and could possibly be
suspended.  To avoid unwanted shutdowns, timeouts will be disabled,
removing the ability to detect and restart frozen JVMs.
------------------------------------------------------------------------

Dann, wenn zum ersten Mal ignorierte Timeouts auslaufen würden, würde der folgende Banner geloggt werden:

------------------------------------------------------------------------
Ping: Timed out waiting for signal from JVM.
The JVM was launched with debug options so this may be because the JVM
is currently suspended by a debugger.  Any future timeouts during this
JVM invocation will be silently ignored.
------------------------------------------------------------------------

• wrapper.java.command (1.0.0)

  Legt den Pfad auf die Java-Befehl fest.

• wrapper.java.command.resolve (1.0.0)

  Spezifiziert, ob der Wrapper versuchen soll, den spezifizierten Java-Befehl aufzulösen.

• wrapper.java.command.loglevel (3.1.2)

  Regelt auf welcher Protokollierungsstufe die erzeugte Befehlszeile geloggt werden wird.

• wrapper.java.detect_debug_jvm (3.3.6)

  Aktiviert die Erkennung eines Debuggers in der Befehlszeile.

• wrapper.java.version.fallback (3.5.38)

  Spezifiziert einen Rückgriffwert, der verwendet wird, wenn das Parsen der Java-Version fehlgeschlagen ist.

• wrapper.java.version.max (3.5.35)

  Spezifiziert die höchste Java-Version, für die der Wrapper die Java-Anwendung starten darf.

• wrapper.java.version.min (3.5.35)

  Spezifiziert die niedrigste Java-Version, für die der Wrapper die Java-Anwendung starten darf.

• wrapper.java.version.output (3.5.17)

  Zeigt die Version der JVM an, die vom Wrapper genutzt wird.

• wrapper.java.version.timeout (3.5.27)

  Konfiguriert die Anzahl an Sekunden, die dem Child-Prozess gewährt wurden, um die JVM-Version auszugeben, bevor sie sich beendete.

• wrapper.registry.java_home (3.2.4)

  Legt einen Registryschlüssel fest, der den Pfad zum Java-Heimatverzeichnis enthält.

• wrapper.registry.java_version (3.5.36) ( Std/Pro )

  Spezifiziert eine anzuwendende Version der JRE, wenn der Java-Befehl aus dem Windows-Registry gesucht wird.