Re: [Wrapper-user] Reset Restart/Failed Invocation Count

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

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