The Wrapper uses a ping system as one of its methods of monitoring the JVM. The Wrapper will send a ping to the JVM and then wait for a ping response. If a response has not been received for more than the time configured in wrapper.ping.timeout property, then the Wrapper will decide that the JVM is frozen and forcibly kill and restart it.

The ping system is fairly reliable, but in some cases when there is heavy disk swapping or another process is hogging resources, the Wrapper can potentially decide that the JVM is frozen when it is simply stuck temporarily. Obviously this is a bad thing as regardless of the cause, the JVM is not in a state where it can reply to requests. But it may be preferable to wait a bit longer rather than restarting the JVM in this case.

If you simply extend the length of the wrapper.ping.timeout property to a large value, false restarts will become much less likely, but at the same time, the Wrapper will also become much less responsive to actual freezes. But you have no idea how common the slow ping responses are or how much extra leeway you have given yourself.

Compatibility :	3.5.16
Editions :
Platforms :

This property allows you specify that the Wrapper should log a warning whenever a ping response of JVM takes longer than a threshold number of seconds.

Starting with Wrapper version 3.5.21, the professional edition of the Wrapper will also fire a jvm_ping_slow event as soon as the threshold is exceeded, and a jvm_ping_response_slow event when the ping response has finally been received.

The default value is 1/4 the length of the ping timeout in seconds.

Setting this property value to "0" (zero) means never log any warnings.

wrapper.ping.alert.threshold=1

wrapper  | Pinging the JVM took 4 seconds to respond.
wrapper  | Pinging the JVM took 9 seconds to respond.
wrapper  | Pinging the JVM took 10 seconds to respond.
wrapper  | Pinging the JVM took 6 seconds to respond.
wrapper  | Pinging the JVM took 2 seconds to respond.

Compatibility :	3.5.16
Editions :
Platforms :

This property allows you specify at which log level the ping alert messages will be logged in the log file.

The default value is "STATUS". The possible values are exactly the same as the console output loglevel, the log file output loglevel, etc.

wrapper.ping.alert.loglevel=STATUS

• wrapper.ping.alert.loglevel (3.5.16)

  Controls at which log level the ping alert messages will be logged.

• wrapper.ping.alert.threshold (3.5.16)

  Prints a warning whenever a ping response takes longer than the specified number of seconds.

• wrapper.ping.interval (3.0.5)

  Configures the number of seconds between two ping requests to the JVM.

• wrapper.ping.interval.logged (3.2.4)

  Configures the number of seconds between two ping requests that should be logged.

• wrapper.ping.timeout (1.0.0)

  Configures the number of seconds to allow between two ping responses coming from the JVM.

• wrapper.ping.timeout.action (3.5.16)

  Configures the actions to take place whenever the ping timeout has expired.

• wrapper.adviser (3.1.0)

  Displays advice whenever certain common problems are detected.

• wrapper.child.status.loglevel (3.4.0) ( Pro )

  Controls the log level of messages related to the child process management.

• wrapper.console.loglevel (1.0.0)

  Filters messages sent to the console according to their log levels.

• wrapper.java.command.loglevel (3.1.2)

  Controls at which log level the generated command line will be logged.

• wrapper.logdialog.loglevel (3.3.1)

  Filters messages of the log dialog according to their log levels.

• wrapper.logfile.loglevel (2.2.5)

  Filters messages sent to the log file according to their log levels.

• wrapper.ping.alert.loglevel (3.5.16)

  Controls at which log level the ping alert messages will be logged.

• wrapper.properties.dump.loglevel (3.5.30)

  Controls at which log level the configuration properties will be logged.

• wrapper.property_warning.loglevel (3.5.21)

  Controls at which log level warnings about invalid property values will be logged.

• wrapper.syslog.loglevel (2.2.5)

  Filters messages sent to the syslog (or event log on Windows) according to their log levels.

• wrapper.event.default.email.maillog.loglevel (3.4.0) ( Pro )

  Filters messages included in the emails according to their log levels.

• wrapper.event.<event_name>.loglevel (3.3.6)

  Controls the log level of messages being logged each time a specific event takes place.

• wrapper.event.<event_name>.message (3.3.6) ( Pro )

  Controls the message which will be logged each time a specific event takes place.

• wrapper.event.<event_name>.command.loglevel (3.3.0) ( Pro )

  Controls the log level of messages related to the event commands being executed.