DO NOT modify any of these parameters unless you have read this property description.
Incorrect settings can cause the Wrapper to fail to operate as expected.
Maximum number of times that the Wrapper will attempt to restart the JVM
if each attempted invocation exits abnormally or is restarted shortly after having being launched.
Must be at least 1. The default value is "5 invocations".
If there are mistakes in the configuration of an application, then the JVM could, for example,
exit with a ClassNotFoundException.
This will be interpreted as the JVM having exited abnormally, leading to a JVM restart.
Obviously, this would lead to an infinite loop of JVM restarts.
To resolve this loop problem, this property sets the maximum number of times that the JVM will be restarted.
If the JVM was running for a period longer than the value set in the
property, then the restart count will be reset to "0" (zero).
So this count only applies to JVM invocations which fail on startup.
In general, this property should be set to a time longer than the period set with the
property as it is designed to count failures on startup or shortly there after.
In most cases, a value of 1 would be acceptable.
But there are cases where some resources may not immediately be available.
For example. On Solaris systems. A server socket may remain bound for
up to 2 minutes after the process which previously had it bound was terminated.
This can lead to cases where a server will start normally.
Then at some later date, when the JVM is restarted for some other reason, getting a
BindException when the new JVM invocation tries to startup.
Setting the value to 5 makes it less likely that the JVM will not be able to restart successfully after a few failures.
Restart requests from the JVM, using the
and restarts which are triggered by a filter are treated like any other restart.
If the request takes place soon after the JVM is launched the restart count will be incremented.