| Compatibility : | 2.2.8 |
| Editions : |    |
| Platforms : |          |
|
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 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).
Setting this property value to "0" (zero) means never extend time out.
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
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 Windows, 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.
|
WARNING
| |
While the ability is there,
be aware that setting this property 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.
|
|
