Re: [Wrapper-user] CPU Timeouts and JVM Restarts

[Leif M. <le...@ta...>]

Mitch,
Version 3.1.1 introduced a new tick based timer which handles heavy loads
much more reliably. It was in 3.1.0 as an experimental feature but had a few
critical bugs.

Upgrade to 3.1.1 and then set the new "wrapper.use_system_timeout=false"
property. See the docs for details:
http://wrapper.tanukisoftware.org/doc/english/prop-use-system-time.html

After receiving more feadback on the reliability of the new tick based timer
from users running on various platforms and environments, the goal is to
make
this new timer the default for future versions of the Wrapper. From my
tests,
it has proved to be much more reliable. The differences between the two
timers are all described in the above docs.

As Paul said, the restarting features are actually very good to have enabled
in the long term. They will save you lots of headaches and worries if your
application every begins having reliability problems. Even with the system
time based timer, there are ways of avoiding restarts by extending (not
disabling)
the various timeouts as Sal mentioned.

Cheers,
Leif


Mi...@bo... wrote:

> I'm currently using v3.1.0 of the wrapper, and I haven't had too many
> problems with it. However, I am now running into a problem where the
> wrapper thinks that my JVM has hung and does an automatic restart. I
> get "Wrapper Process has not received any CPU time for 38 seconds.
> Extending timeouts." and immediately following that I get a JVM restart.
> My service is running on machines that experience heavy load, and my
> service itself is a fairly large multi-threaded application that will
> produce its own heavy load. I would rather attempt to "ignore" the
> whole CPU/Ping etc. timeout values because I don't want my JVM to be
> automatically restarted. What is the best way to set all of the
> timeout/interval configuration parameters so that I can ignore these
> checks, and deal with the consequences of a "hung" JVM with a manual
> intervention?
> Thanks,
> Mitch