Reset Restart/Failed Invocation Count

[Darren-25]

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


------------------------------------------------------------------------------
_______________________________________________
Wrapper-user mailing list
Wrapper-user@...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Leif Mortenson-2]

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<darrenslists@...> 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

------------------------------------------------------------------------------
_______________________________________________
Wrapper-user mailing list
Wrapper-user@...
https://lists.sourceforge.net/lists/listinfo/wrapper-user

[Darren-25]

> Once the
> JVM has been running for that amount of time, the restart count will
> be reset.

Aha, it even says that in the documentation, I should have read more  
carefully!

For testing, the upgrade process is in a loop, so the application  
never runs for more than 60s without restart.  As you say, this won't  
be a problem in production.

Thanks,
Darren


------------------------------------------------------------------------------
_______________________________________________
Wrapper-user mailing list
Wrapper-user@...
https://lists.sourceforge.net/lists/listinfo/wrapper-user