-
wrapper_start -
Fired when the Wrapper process first starts.
This event can be used to do any initialization that must be done before the first JVM is launched.
In the case of emails,
it can be used to indicate that the system has just been rebooted, for example.
-
jvm_prelaunch -
Fired whenever a new JVM is about to be launched.
This event can be used to do any initialization that must be done before the each JVM is launched.
-
jvm_start -
Fired immediately after a new JVM has been launched but before its application is started.
-
jvm_started -
Fired once the Wrapper code in the JVM has notified the Wrapper process
that the new application is up and running.
Note that unless Integration Method 3 (WrapperListener)
is being used, this may be fired before the user application is actually fully up.
Depending on the user application,
both Method 1 (WrapperSimpleApp)
and Method 2 (WrapperStartStopApp)
can also be configured to wait
until the application is fully started before reporting that it is up.
See the "Advanced" section of each Integration Method for details.
-
jvm_deadlock (ver. 3.5.0 or later) -
Fired whenever a thread deadlock is detected within the JVM with the
Check Deadlock feature.
-
jvm_stop -
Fired whenever a JVM is about to be shutdown.
The event will be fired if the JVM crashes but it will happen after the JVM process is gone.
If the system crashes or loses power for any reason, the event will never be fired.
-
jvm_stopped -
Fired after a JVM is shutdown for any reason.
This event can be used to do any cleanup.
If the system crashes or loses power for any reason, the event will never be fired.
-
jvm_restart -
Fired when the Wrapper is about to restart a JVM.
-
jvm_failed_invocation -
Fired when the JVM has exited in a state which results in a restart,
but the total time that the JVM was running was less than the configured
wrapper.successful_invocation_time property.
-
jvm_max_failed_invocations -
Fired when the JVM has exited in a state which results in a restart,
but the failed invocations (jvm_failed_invocation event) is counted up,
the total number of consecutive failed invocations is more than the configured
wrapper.max_failed_invocations property.
-
jvm_kill -
Fired when the Wrapper has decided that a JVM which it believed to be frozen needs to be killed.
This happens before the JVM process is killed.
This event will always be preceded by the jvm_stop event
then followed by the jvm_killed
and jvm_stopped events.
-
jvm_killed -
Fired when the Wrapper has killed a JVM which it believed to be frozen.
This event will always be followed by the jvm_stopped event.
-
jvm_unexpected_exit -
Fired when the JVM process disappears for an unexpected reason.
For example when it crashes. This event will always be followed by
the jvm_stop and
jvm_stopped events.
-
wrapper_stop -
Fired last when the Wrapper process is shutting down.
This event can be used to do any cleanup that must be done after the last JVM is shutdown.
Note that this event will only be fired if the Wrapper is shutdown normally.
If the system crashes or loses power for any reason, the event will never be fired.
-
wrapper_pause (ver. 3.5.0 or later) -
Fired whenver the Wrapper is paused. Depending on the configuration of how the
Wrapper behaves when paused, events about the JVM being stopped will also be fired.
See the wrapper.pausable and
wrapper.pausable.stop_jvm
properties for more details.
-
wrapper_resume (ver. 3.5.0 or later) -
Fired whenver the Wrapper is resumed. Depending on the configuration of how the
Wrapper behaves when paused, events about the JVM being started will also be fired.
See the wrapper.pausable and
wrapper.pausable.stop_jvm
properties for more details.
-
user_<n> (ver. 3.5.0 or later) -
User event which is fired in response to an Action.
The '<n>' component of the event name is any integer in the range 1 to 32767.
Actions which can be configured to fire a user event include;
wrapper.filter.action.<n>,
wrapper.timer.<n>.action,
wrapper.check.deadlock.action,
and wrapper.event.<event_name>.command.block.action.
