|
From: Leif M. <le...@ta...> - 2004-07-27 00:36:45
|
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 |