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.
Defaults to 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 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
wrapper.successful_invocation_time
property, then the restart count will be reset to 0. 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
wrapper.startup.timeout
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
WrapperManager.restart() method,
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.
Example: |
wrapper.max_failed_invocations=5
|
|