• wrapper.ping.timeout property
• wrapper.ping.timeout.action property

Compatibility :	1.0.0
Editions :
Platforms :

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

The default value is "30 seconds".

wrapper.ping.timeout=30

Setting this property value to "0" (zero) means never time out. The ping timeout must be at least 5 seconds longer than the value of wrapper.ping.interval. The Wrapper will modify the value at run time if necessary to avoid problems.

In normal operation, the Wrapper pings the JVM once every 5 seconds to make sure that its process has not frozen up. The ping timeout is the amount of time to allow for 2 responses from the JVM before the Wrapper assumes that it is hung and restarts it.

This property also controls the amount of time that the JVM will allow to pass without being pinged by the Wrapper. If the Wrapper does not ping the JVM for longer than the specified timeout, it will exit allowing the Wrapper to resynch by launching a new JVM. This also makes sure that the JVM will exit if the Wrapper process is terminated abnormally. (By killing the Wrapper process in the Windows Task Manager, or using "kill -9" signal on UNIX systems.)

With the addition of the wrapper.cpu.timeout property, there is now almost no reason why you should ever need to change this property. The only reasons why you should be getting ping timeouts are if the system is under heavy load or if the JVM is really hung. The CPU timeout should now detect any problems in with CPU.

Compatibility :	3.5.16
Editions :
Platforms :

This property allows to specify a certain action, which will be performed, whenever a ping timeout takes place after the seconds specified in wrapper.ping.timeout property above. The actions are based on the actions, which are commonly usable at various places in the Wrapper, e.g. deadlock, event, filter, etc.

For consistency and backwards compatibility is the default action specified as RESTART.

wrapper.ping.timeout.action=RESTART

Possible actions are:

• DEBUG (Since ver. 3.5.0) :

  will cause a debug message to be logged. This is only really useful in helping to understand when the action is fired.

• DUMP (Since ver. 3.3.6) :

  will invoke a thread dump.

• GC (Since ver. 3.5.7) :

  will invoke a full garbage collection sweep in the JVM. Be aware that doing this frequently can affect performance of the JVM as a full sweep will often cause all threads to freeze for the duration of the GC.

• RESTART :

  will stop the current JVM and then restart a new invocation.

• SHUTDOWN :

  will stop the JVM as well as the Wrapper.

• USER_<n> (Since ver. 3.5.0, Professional Edition) :

  will cause a user defined event to be fired. This can be either the sending of an email, or the execution of an external system command. The command could be anything from performing clean up operations to raising an SNMP trap.

• PAUSE (Since ver. 3.5.0) :

  will pause the Java application if pausing is enabled and the JVM is running. See the wrapper.pausable property for details.

• RESUME (Since ver. 3.5.0) :

  will resume the Java application if it is in a paused state. This could be used if the JVM is not stopped when paused. See the wrapper.pausable property for details.

• SUCCESS (Since ver. 3.5.5) :

  will tell the Wrapper to reset its internal failed invocation count and count the current JVM invocation as "successful". This can be useful in applications which are designed to restart with a fairly short frequency.

• NONE :

  is useful because it will prevent any triggers with a higher number from being triggered.

Chaining Multiple Actions:

It is possible to specify more than one action by separating them with a space or comma. When more than one action is specified, they will be executed in rapid succession in the order specified.

The following example will attempt to perform a thread dump and then restart the JVM. The thread dump will only take place if the JVM is not fully frozen.

wrapper.ping.timeout.action=DUMP,RESTART

• 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.cpu.timeout (2.2.8)

  Configures the number of seconds without CPU before the JVM sends a warning and extend timeouts.

• wrapper.max_hostid_timeout (3.4.0) ( Std/Pro )

  Configures the maximum number of seconds the Wrapper should wait for network interfaces to come up.

• wrapper.logfile.close.timeout (3.5.21)

  Controls the number of seconds at which the log file should close after the last log entry.

• wrapper.logfile.flush.timeout (3.5.21)

  Configures the interval in seconds at which the Wrapper flushes all outputs to the log file.

• wrapper.logfile.inactivity.timeout (3.2.0, deprecated as of 3.5.21)

  Controls the number of seconds at which the log file should close after the last log entry.

• wrapper.ping.timeout (1.0.0)

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

• wrapper.startup_thread.timeout (3.5.11)

  Configures the number of seconds to allow asynchronous startup operations to be completed.

• wrapper.startup.timeout (1.0.0)

  Configures the number of seconds to allow between the time the Wrapper launches the JVM and the time the JVM responds that the application has started.

• wrapper.shutdown.timeout (2.2.7)

  Configures the number of seconds to allow between the time the Wrapper asks the JVM to shutdown and the time the JVM responds that it is stopping.

• wrapper.jvm_exit.timeout (2.2.8)

  Configures the number of seconds to allow between the time the JVM reports it is stopped and the time the JVM process actually terminates.

• wrapper.jvm_cleanup.timeout (3.4.0)

  Configures the number of seconds allowed for the Wrapper to clean up child processes after the JVM has been shutdown.

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

  Configures how long the Wrapper will wait for a configured event to complete.

• wrapper.event.<event_name>.email.receive.timeout (3.3.2) ( Pro )
• wrapper.event.<event_name>.email.send.timeout (3.3.2) ( Pro )