Hosted by:

wrapper.cpu.timeout Property

wrapper.cpu.timeout Property

Configuration Property Overview

- Configuration Property Overview
- Advanced Properties
- Property List by Name

wrapper.cpu.timeout

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 less than the other timeouts (wrapper.startup.timeout, wrapper.ping.timeout, and wrapper.shutdown.timeout). 0 means never extend time outs. Defaults to 10 seconds.

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.

    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 which 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 NT, is when the machine is very low on memory leading to lots of disk swapping. If the total memory is 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, the system 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. The 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.

Example:

    wrapper.cpu.timeout=10

WARNING |  | While the ability is there. Be aware that setting this property to 0 or a value larger 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.

by Leif Mortenson

Copyright ©1999-2004 by Tanuki Software. All Rights Reserved. | last modified: