The Wrapper is able to send emails and/or execute external commands in response to a number of events.
The following list describes each of the defined events:
-
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_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 result in a restart
but the total time that the JVM was running was less than the configured
wrapper.successful_invocation_time.
-
jvm_max_failed_invocations:
Fired when the JVM has exited in a state which result in a restart
but the total time that the JVM was running was less than the configured
wrapper.successful_invocation_time
and the total number of consecutive failed invocations is more than the configured
wrapper.max_failed_invocations.
-
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
but 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.
