Compatibilidad :	3.3.6
Ediciones :
Plataformas :

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)

  Establece la ruta al ejecutable de Java.

• wrapper.java.command.resolve (1.0.0)

  Especifica si el Wrapper debe intentar resolver el comando especificado de Java o continuar usando la ruta no resuelta como posiblemente definida.

• wrapper.java.command.loglevel (3.1.2)

  Controla en qué nivel de registro se registrará la línea de comandos generada.

• wrapper.java.detect_debug_jvm (3.3.6)

  Habilita la detección de un depurador en la línea de comandos.

• wrapper.java.version.fallback (3.5.38)

  Especifica un valor de reserva que se utilizará cuando la versión de Java no se haya analizado.

• wrapper.java.version.max (3.5.35)

  Especifica la versión máxima de Java para la cual el Wrapper puede iniciar la aplicación Java.

• wrapper.java.version.min (3.5.35)

  Especifica la versión mínima de Java para la cual el Wrapper puede lanzar la aplicación Java.

• wrapper.java.version.output (3.5.17)

  Muestra la versión de la JVM utilizada por el Wrapper.

• wrapper.java.version.timeout (3.5.27)

  Configura el número de segundos permitidos para que el proceso hijo imprima la versión de JVM antes de que se termine.

• wrapper.registry.java_home (3.2.4)

  Especifica una clave de registro que contiene la ruta de acceso a la carpeta principal de Java.

• wrapper.registry.java_version (3.5.36) ( Estándar/Profesional )

  Especifica una versión del JRE que se debe usar al ubicar el comando Java desde el registro de Windows.