Compatibilidad :	3.3.0
Ediciones :
Plataformas :

The Java Service Wrapper has the ability to notify a system administrator via email, as well as react to a wide range of built-in and user-defined events.

• Event Configuration Properties
• Event Types
• Event Mails
• Event Commands

This section includes a full list of properties which can be used to configure and control how the Wrapper reacts to events.

General Event Properties:

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

  Controla el nivel de registro de los mensajes siendo registrados cada vez que se produce un evento específico.

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

  Controla el mensaje que se registrará cada vez que se produzca un evento específico.

• wrapper.event.<event_name>.set_environment (3.3.0, descontinuado en 3.3.6) ( Profesional )

Event Email Properties:

Configuración de Alerta de Email:

• wrapper.event.<event_name>.email (3.3.0) ( Profesional )

  Configura si se deben enviar emails para un evento en particular.

Sistema de Email:

• wrapper.event.<event_name>.email.client.host (3.3.2) ( Profesional )

  Establece el nombre de la máquina que ejecuta el Wrapper, que se envía al servidor SMTP.

• wrapper.event.<event_name>.email.smtp.host (3.3.0) ( Profesional )

  Configura el host SMTP al que el Wrapper intentará conectarse al enviar emails.

• wrapper.event.<event_name>.email.smtp.port (3.3.0) ( Profesional )

  Configura el puerto SMTP al que el Wrapper intentará conectarse al enviar emails.

• wrapper.event.<event_name>.email.smtp.auth.type (3.5.3) ( Profesional )

  Especifica un método de autenticación que se utilizará al conectarse a un servidor SMTP.

• wrapper.event.<event_name>.email.smtp.auth.userid (3.5.3) ( Profesional )

  Especifica la ID de usuario que se utilizará para la autenticación cuando se conecte a un servidor SMTP.

• wrapper.event.<event_name>.email.smtp.auth.password (3.5.3) ( Profesional )

  Especifica la contraseña que se utilizará para la autenticación cuando se conecte a un servidor SMTP.

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

  Configura el número máximo de segundos que se debe aguardar una respuesta del servidor SMTP después que un comando es enviado por el Wrapper.

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

  Configura el número máximo de segundos que el Wrapper debe esperar cuando intenta enviar un comando al servidor SMTP.

• wrapper.event.<event_name>.email.debug (3.3.0) ( Profesional )

  Imprime información detallada cuando se envían emails.

Cuerpo de Email:

• wrapper.event.<event_name>.email.sender (3.3.0) ( Profesional )

  Configurar la dirección del remitente de los emails.

• wrapper.event.<event_name>.email.recipient (3.3.0) ( Profesional )

  Especifica el(los) destinatario(s) de los emails.

• wrapper.event.<event_name>.email.subject (3.3.0) ( Profesional )

  Configura el asunto de los emails.

• wrapper.event.<event_name>.email.body (3.3.0) ( Profesional )

  Configura el cuerpo del mensaje de los correos electrónicos.

• wrapper.event.<event_name>.email.attach_log (3.4.0, descontinuado en 3.5.31) ( Profesional )

  Permite enviar archivos de registro adjuntos a emails de notificación enviados por el Wrapper.

• wrapper.event.<event_name>.email.maillog (3.5.31) ( Profesional )

  Permite enviar registros como un archivo adjunto o directamente en el cuerpo de los mensajes de los emails.

• wrapper.event.default.email.maillog.lines (3.4.0) ( Profesional )

  Especifica el número de líneas de los registros incluidos en los emails.

• wrapper.event.default.email.maillog.format (3.4.0) ( Profesional )

  Configura el formato de los registros incluidos en los emails.

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

  Filtra los mensajes incluidos en los emails de acuerdo con sus niveles de registro.

Event Command Properties:

• wrapper.event.<event_name>.command.argv.<n> (3.3.0) ( Profesional )

  Especifican un comando (y sus argumentos) que se ejecutará(n) en respuesta a un evento específico.

• wrapper.event.<event_name>.command.block (3.4.1) ( Profesional )

  Indica al Wrapper si debe esperar o no que el comando se complete antes de permitir que el Wrapper continúe.

• wrapper.event.<event_name>.command.block.action (3.4.1) ( Profesional )

  Configura la acción a realizarse siempre que un comando de evento configurado no logra completarse dentro del tiempo de espera especificado.

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

  Configura cuanto tiempo el Wrapper esperará a que un evento configurado se complete.

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

  Controla el nivel de registro de los mensajes relacionados con los comandos de evento que se están ejecutando.

• wrapper.event.<event_name>.command.new_process_group (3.5.47) ( Profesional )

  Especifica si el comando de eventos debe iniciarse en un nuevo grupo de procesos.

• wrapper.event.<event_name>.command.on_exit.<n> (3.3.0) ( Profesional )

  Controlan qué hará el Wrapper en respuesta a los códigos de salida específicos de comandos de eventos.

• wrapper.event.<event_name>.command.privileges.disable (3.5.57) ( Profesional )

  Deshabilita los privilegios para los comandos de eventos.

• wrapper.event.<event_name>.command.privileges.enable (3.5.57) ( Profesional )

  Habilita privilegios para comandos de eventos.

• wrapper.event.<event_name>.command.privileges.remove (3.5.57) ( Profesional )

  Elimina privilegios de los tokens de acceso de los comandos de eventos.

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 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 (Since ver. 3.5.0) :

  Fired whenever a thread deadlock is detected within the JVM with the Check Deadlock feature.

• jvm_ping_slow :

  Fired when a ping is first determined to be slower than the number of seconds specified by wrapper.ping.alert.threshold. The event will be fired before the ping has been responded.

• jvm_ping_response_slow :

  Fired when a ping is determined to be slower than the number of seconds specified by wrapper.ping.alert.threshold. The event will be fired after the ping has been responded.

• jvm_ping_timeout :

  Fired when the time between two ping responses took longer than the number of seconds specified by wrapper.ping.timeout.

• 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. See the wrapper.jvm_kill.delay property if a delay is needed when executing commands for this event.

• 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 shut down.

  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 (Since ver. 3.5.0) :

  Fired whenever 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 (Since ver. 3.5.0) :

  Fired whenever 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> (Since ver. 3.5.0) :

  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.

The Wrapper is able to send out alert emails to in response to certain events. Emails can be sent out with a customized message, along with a fragment of the Wrapper's log file. This makes it possible for a system administrator to decide whether or not it is necessary to take further action. See the documentation of individual properties for details on their use.

# Common Event Email settings.
#wrapper.event.default.email.debug=TRUE
wrapper.event.default.email.smtp.host=smtp.mycompany.com
wrapper.event.default.email.smtp.port=25
wrapper.event.default.email.subject=[%WRAPPER_HOSTNAME%:%WRAPPER_NAME%:%WRAPPER_EVENT_NAME%] Event Notification
wrapper.event.default.email.sender=myapp-noreply@mycompany.com
wrapper.event.default.email.recipient=myapp-admin@mycompany.com

# Event specific settings.
wrapper.event.jvm_restart.email=TRUE
wrapper.event.jvm_restart.email.body=The JVM was restarted.\n\nPlease check on its status.\n

The properties are all of the form wrapper.event.<x>.email* where <x> component is either the keyword default, or one of the Event Types defined above.

Whenever a property is not specifically defined for any of the event names, the default value wrapper.event.default.email* will be used. This is useful for setting values which will be common to all event emails.

The Wrapper is able to execute external commands in response to certain events. These can be useful for doing system cleanup, sending out notifications, or taking actions which can only be handled natively. See the documentation of individual properties for details on their use.

It is possible to instruct the Java Service Wrapper to launch the command and forget about it, block until the command has completed, or wait a maximum time for the command to complete. If the wait times out, the command will be left running.

The Wrapper does not currently provide for a way to log the output of the external commands.

wrapper.event.jvm_prelaunch.command.argv.1=/usr/bin/mycleanup
wrapper.event.jvm_prelaunch.command.argv.2=parameter1

wrapper.event.jvm_prelaunch.command.argv.1=/usr/bin/mycleanup
wrapper.event.jvm_prelaunch.command.argv.2=parameter1
wrapper.event.jvm_prelaunch.command.block=TRUE

wrapper.event.jvm_prelaunch.command.argv.1=/usr/bin/mycleanup
wrapper.event.jvm_prelaunch.command.argv.2=parameter1
wrapper.event.jvm_prelaunch.command.block=TRUE
wrapper.event.jvm_prelaunch.command.block.timeout=5

The properties are all of the form wrapper.event.<x>.command.* where <x> component is one of the Event Types defined above.

Whenever a property is not specifically defined for any of the event names, the default value wrapper.event.default.command.* will be used. This is useful for setting values which will be common to all event commands.