|
From: Leif M. <le...@ta...> - 2009-07-22 12:02:50
|
Darren, She successful invocation time is the minimum amount of time that the JVM must be running before it will be considered to be a successful invocation. In your case it is 300 seconds (5 minutes). Once the JVM has been running for that amount of time, the restart count will be reset. The max failed invocations is the maximum number of times that the Wrapper will attempt to launch JVM invocations where each one is running less than the above successful invocation time. Assuming that your normal application is running for a long period of time, your double restart should not pose any problems even with the default settings. In your testing, it sounds like you were doing lots of rapid restarts. That is most likely a special case. If you set the successful invocation time to 1 second then you could continue to restart the JVM indefinitely as each would be running for more than a second. I hope this helps. Cheers, Leif On Wed, Jul 22, 2009 at 7:44 PM, Darren<dar...@go...> wrote: > I have a java application, running under the wrapper, which is able > to update itself and signal a restart to the wrapper using an exit > code. Each application upgrade requires the wrapper restarts the JVM > twice in quick succession. > > In testing I let the application upgrade itself repeatedly and it > fell over at 5 restarts. Looking through the docs I see the > following properties can be updated to change this. > > wrapper.max_failed_invocations=5 > wrapper.successful_invocation_time=300 > > My question is, does the failed invocation count ever get reset? > > If not, I'm going to need to increase wrapper.max_failed_invocations > based on twice the estimated number of upgrades before the physical > server is restarted. > > Alternatively I could delay the upgrades so > wrapper.successful_invocation_time passes before a restart is signalled. > > Either of these workarounds shouldn't be a problem, just wondering if > there is another solution? > > Thanks, > Darren |