wrapper.jvm_terminate.timeout
Compatibility :3.5.18
Editions :Professional EditionStandard EditionCommunity Edition
Platforms :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/OSIBM z/Linux

WARNING

DO NOT modify any of these parameters unless you have read this property description. Incorrect settings can cause the Wrapper to fail to operate as expected.

Number of seconds to allow between the time that the Wrapper asks the system to forcibly terminate the JVM process and the time that the Wrapper verifies that the JVM has actually been terminated.

Positive values must be in the range 5-1728000 seconds (20 days).

The default value is "0" (zero) which means never time out.

NOTE

Prior to version 3.5.54, default value was "10 seconds".

The new default behavior of waiting for the Java process to terminate as long as necessary was chosen because the alternative would be to stop the wrapper, which would negate any possibility of restarting the application.

Example: 
wrapper.jvm_terminate.timeout=10

In most cases this property should not need to be adjusted. Setting it too short could have adverse affects.

In almost all cases the system will be able to forcibly terminate a process, assuming it has access to do so. We received reports from a couple users on Windows where a request to terminate a frozen JVM process was returning successfully, but the JVM process was never actually being terminated. This unfortunately is an unrecoverable state for the Wrapper. Implementation of this property was done to allow the Wrapper to accurately explain the problem in the logs and then shutdown cleanly. 

wrapper  | Timed out waiting for the OS to forcibly terminate the JVM process, unable to continue.
wrapper  |   The scheduled restart of the JVM has been cancelled.

If you see this problem, please contact support about it as we are interested in finding an environment where it can be reproduced reliably.

Reference: Timeout
  • wrapper.cpu.timeout (2.2.8)

    Configures the number of seconds without CPU before the JVM sends a warning and extend timeouts.

  • wrapper.max_hostid_timeout (3.4.0) ( Std/Pro )

  • wrapper.logfile.close.timeout (3.5.21)

    Controls the number of seconds at which the log file should close after the last log entry.

  • wrapper.logfile.flush.timeout (3.5.21)

    Configures the interval in seconds at which the Wrapper flushes all outputs to the log file.

  • wrapper.logfile.inactivity.timeout (3.2.0, deprecated as of 3.5.21)

    Controls the number of seconds at which the log file should close after the last log entry.

  • wrapper.ping.timeout (1.0.0)

    Configures the number of seconds to allow between two ping responses coming from the JVM.

  • wrapper.startup_thread.timeout (3.5.11)

    Configures the number of seconds to allow asynchronous startup operations to be completed.

  • wrapper.startup.timeout (1.0.0)

    Configures the number of seconds to allow between the time the Wrapper launches the JVM and the time the JVM responds that the application has started.

  • wrapper.shutdown.timeout (2.2.7)

    Configures the number of seconds to allow between the time the Wrapper asks the JVM to shutdown and the time the JVM responds that it is stopping.

  • wrapper.jvm_exit.timeout (2.2.8)

    Configures the number of seconds to allow between the time the JVM reports it is stopped and the time the JVM process actually terminates.

  • wrapper.jvm_cleanup.timeout (3.4.0)

    Configures the number of seconds allowed for the Wrapper to clean up child processes after the JVM has been shutdown.

  • wrapper.jvm_terminate.timeout (3.5.18)

    Configures the number of seconds to allow from the time that the Wrapper asks the system to forcibly terminate the JVM until it confirms that the process actually stopped.

Reference: Shutdown

The Java Service Wrapper provides a full set of configuration properties that allows you to make the Wrapper meet your exact needs. Please take a look at the documentation for the individual properties to see all of the possibilities beyond the examples shown above.