Compatibility :	3.3.6
Editions :
Platforms :

The Wrapper has several features which are designed to detect when a JVM has frozen, or otherwise become unstable. Normally these features should all be left enabled. However, when a JVM is connected to a debugger, it is common for the JVM to intentionally be frozen as various debugging operations take place. In these cases, the Wrapper would normally think the JVM was frozen, and kill and restart it in the middle of a debug session. The Wrapper works around this problem by checking the configured Java command line and ignoring certain timeouts when it detects that a debugger is in use. This property makes it possible to enable or disable this debugging check. The default value is "TRUE", which will detect the debugging and ignore certain timeouts.

wrapper.java.detect_debug_jvm=TRUE

Debugger Detection:

The Wrapper will decide that the JVM is using a debugger if the wrapper.java.command property is set to "jdb" or "jdb.exe" or if one of the wrapper.java.additional.<n> properties is set to "-Xdebug".

When the Wrapper detects that a debugger is in use, the following banner will be logged on startup:

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

Then the first time that any of the ignored timeouts expire, the following banner will be logged:

------------------------------------------------------------------------
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)

  Sets the path to the Java executable.

• wrapper.java.command.resolve (1.0.0)

  Specifies whether the Wrapper should try to resolve the specified Java command or continue using the unresolved path as possibly defined.

• wrapper.java.command.loglevel (3.1.2)

  Controls at which log level the generated command line will be logged.

• wrapper.java.detect_debug_jvm (3.3.6)

  Enables the detection of a debugger in the command line.

• wrapper.java.version.fallback (3.5.38)

  Specifies a fallback value to be used when the Java version failed to be parsed.

• wrapper.java.version.max (3.5.35)

  Specifies the maximum version of Java for which the Wrapper is allowed to launch the Java Application.

• wrapper.java.version.min (3.5.35)

  Specifies the minimum version of Java for which the Wrapper is allowed to launch the Java Application.

• wrapper.java.version.output (3.5.17)

  Displays the version of the JVM used by the Wrapper.

• wrapper.java.version.timeout (3.5.27)

  Configures the number of seconds allowed for the child process to print the JVM version before it is terminated.

• wrapper.registry.java_home (3.2.4)

  Specifies a registry key containing the path to the Java home folder.

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

  Specifies a version of the JRE to use when locating the Java command from the Windows registry.