wrapper.cpu.timeout
Compatibility :2.2.8
Editions :Professional EditionStandard EditionCommunity Edition
Platforms :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM 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.

NOTE

This property is ignored unless wrapper.use_system_time=TRUE.

When wrapper.use_system_time=FALSE, similar notifications about system time changes and delays due to heavy loading can be logged using the wrapper.timer_fast_threshold and wrapper.timer_slow_threshold properties.

This property sets the number of seconds without CPU before the JVM will issue a warning and extend timeouts. In order for this property to have any effect, it must have a value lower than the other timeout properties (wrapper.startup.timeout, wrapper.ping.timeout, and wrapper.shutdown.timeout). Setting this property value to "0" (zero) means to never extend the timeout.

The default value is "10 seconds".

Example: (10 seconds) 
wrapper.cpu.timeout=10

If the Wrapper detects that it was denied CPU for an extended period of time, you may see messages like the following from the Wrapper, the JVM, or both.

Log Example: 
INFO   | wrapper  | Wrapper Process has not received any CPU time for 27 seconds.
                    Extending timeouts.
INFO   | jvm 1    | JVM Process has not received any CPU time for 27 seconds.
                    Extending timeouts.

These messages are warnings that, in this case, both the Wrapper and its JVM process were denied access to the CPU for a period of 27 seconds. Depending on the current state of the Wrapper, either the startup, ping, or shutdown timeout is extended to avoid a FALSE timeout caused by the lack of processing power.

There are two cases where either the Wrapper or its controlled JVM could be denied access to the CPU for an extended period of time. Either could lead to the Wrapper thinking that the JVM was hung, causing it to be restarted or shutdown because one or more of the timeouts expired.

The first way that this can happen is when the Wrapper is competing for system resources with another process that has the habit of consuming 100% of the CPU for extended periods of time without yielding to other processes. Most modern operating systems are fairly good about managing multitasking, but there are still cases where it can fail. One example of this on Windows is when the machine is very low on memory, leading to lots of disk swapping. If the total memory is not large enough, the entire system can freeze up for as long as a minute before any applications are again given any CPU cycles.

In most cases, when you are having problems with CPU timeouts, you should really look at finding a way to resolve the problem of the Wrapper not getting any CPU rather than extending any timeouts. If the application being run by the Wrapper is not getting any CPU, then it will not be able to reliably service requests from clients.

A second way is if the system is suspended and then resumed. This is a common thing to do on notebooks. When the system comes back up, it will appear to have suddenly been set ahead by potentially several hours.

By default, warning messages will be displayed after 10 seconds, which is actually quite a while. CPU timeout being triggered will not have any adverse effects on an application other than the message being displayed in the logs. To avoid this message being logged, the timeout can be set to a larger value or disabled completely.

WARNING

While the ability is there, be aware that setting this property value to "0" (zero) (= disable Timeout) or a larger value than another timeout could cause that timeout to be falsely triggered in cases of heavy load. This can lead to the JVM being restarted when a restart is not really necessary.

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.