Notas de la versión de Sun Java System Message Queue 4.1

Acerca de Message Queue 4.0

Message Queue 4.0 es una versión que se limita a ser compatible con Application Server 9 PE. Se trata de una versión menor que incluye unas cuantas funciones nuevas, mejoras menores y soluciones de fallos. Esta sección incluye la siguiente información.

Novedades de la versión 4.0

Message Queue 4.0 incluye las siguientes funciones nuevas:

Se describen en las secciones secundarias siguientes.

Precaución –

Uno de los cambios más insignificantes que incorpora la versión 4.0, pero que puede provocar interrupciones, es la desaprobación de la opción command-line para especificar una contraseña. En lo sucesivo, deberá guardar todas las contraseñas en un archivo, tal y como se describe en Opción de contraseña desaprobada.

Cambios de interfaz en el API C y en el tiempo de ejecución del cliente C

La versión 4.0 de Message Queue incorpora dos nuevas propiedades que se establecerán en todos los mensajes que se hayan colocado en la cola de mensajes inactivos.

JMS_SUN_DMQ_PRODUCING_BROKER indica al agente dónde se generó el mensaje.
JMS_SUN_DMQ_DEAD_BROKER indica al agente quién marcó el mensaje como inactivo.

Cambios de interfaz en el API de Java y en el tiempo de ejecución del cliente de Java

La versión 4.0 de Message Queue incorpora dos nuevas propiedades que se establecerán en todos los mensajes que se hayan colocado en la cola de mensajes inactivos.

JMS_SUN_DMQ_PRODUCING_BROKER indica al agente dónde se generó el mensaje.
JMS_SUN_DMQ_DEAD_BROKER indica al agente quién marcó el mensaje como inactivo.

Muestra información sobre el almacén persistente

El subcomando query se ha añadido al comando imqdbmgr. Utilice este comando para mostrar información sobre el almacén persistente, como la versión del almacén, el usuario de la base de datos y si se han creado las tablas de la bases de datos.

A continuación, se muestra un ejemplo de la información mostrada por este comando.

imqdbmgr query

[04/Oct/2005:15:30:20 PDT] Utilizando el almacén persistente conectado:
        versión=400
        Iddebroker=Mozart1756
        url de la conexión de la base de datos=jdbc:oracle:thin:@Xhome:1521:mqdb
        usuario de la base de datos=scott
Ejecutándose en modo individual.
Ya se han creado las tablas de la base de datos.

Cambios en el formato del almacén persistente.

La versión 3.7 UR1 de Message Queue introdujo dos cambios en el formato del almacén persistente para mejorar el rendimiento: uno en el almacén del archivo, y el otro en el almacén de JDBC.

El formato de los datos de transacción se mantuvo en el almacén del archivo.

El formato de la información del estado de la transacción almacenado en el almacén persistente basado en archivos de Message Queue se cambió para reducir la E/S del disco y mejorar el rendimiento de las transacciones JMS.
Almacén Oracle JDBC

En versiones anteriores de Message Queue, el esquema del almacén para Oracle utilizaba el tipo de datos LONG RAW para guardar datos de mensajes. En Oracle 8, Oracle introdujo los tipos de datos BLOB y dejó de utilizar el tipo LONG RAW. BLOBductName; 3.7 UR1 cambió al tipo de datos BLOB para mejorar el rendimiento y la compatibilidad.

Dado que estos cambios afectan a la compatibilidad del almacén, la versión del almacén basado en archivos y en JDBC pasó de la 350 a la 370 en la versión 3.7 UR1 de Message Queue.

La versión 4.0 de Message Queue introdujo algunos cambios en el almacén JDBC para optimizar y admitir futuras mejoras. Por este motivo, se actualizó la versión del almacén JDBC a la 400. También es necesario señalar que, en la versión 4.0, la versión del almacén persistente basado en archivos sigue siendo la 370 porque no se han efectuado cambios en él.

Message Queue 4.0 admite la conversión automática del almacén persistente a las versiones más recientes de los almacenes persistentes basados en archivos y en JDBC. Si la utilidad detecta un almacén más antiguo la primera vez que se inicie imqbrokerd, cambiará el almacén al nuevo formato, prescindiendo del almacén antiguo.

Las versiones 200 y 350 del almacén basado en archivos se convertirán al formato de la versión 370.
Las versiones 350 y 370 del almacén basado en JDBC se convertirán al formato de la versión 400. (Si necesita actualizar un almacén de la versión 200, tendrá que pasar previamente por alguna de las versiones intermedias: 3.5 ó 3.6.)

Si necesita deshacer esta actualización, puede desinstalar Message Queue 4.0 y después volver a instalar la versión que estaba ejecutando anteriormente. Como la copia antigua del almacén se deja intacta, el agente puede ejecutarse con la copia antigua del almacén.

Administración del agente

La utilidad (imqcmd) ha incorporado un subcomando y varias opciones que permiten a los administradores desactivar el agente o cerrarlo después del intervalo especificado, destruir una conexión o establecer las propiedades del sistema java (por ejemplo, las propiedades relacionadas con la conexión.)

Al desactivar el agente, éste pasa a un estado inactivo, lo cual permite drenar los mensajes antes de cerrar o reiniciar el agente. No es posible crear conexiones nuevas con un agente que está desactivado. Para desactivar el agente, introduzca un comando como el siguiente:

imqcmd quiesce bkr -b Wolfgang:1756
Para que el agente se cierre después del intervalo especificado, introduzca un comando como el siguiente: (El intervalo de tiempo especifica el número de segundos que debe transcurrir para que se cierre el agente.)

imqcmd shutdown bkr -b Hastings:1066 -time 90

Si especifica un intervalo de tiempo, el agente registrará un mensaje indicando cuándo se producirá el cierre. Por ejemplo:

El agente se cerrará en 29 segundos (29996 milisegundos)

Mientras el agente espera a que se produzca el cierre, su comportamiento se verá afectado de la siguiente forma:
- Seguirá aceptando las conexiones jms administrativas.
- No aceptará nuevas conexiones jms.
- Las conexiones jms existentes continuarán funcionando.
- El agente no podrá sustituir a ningún otro agente de un clúster de alta disponibilidad.
- La utilidad imqcmd no se bloqueará, sino que enviará la solicitud de cerrar el agente e informará inmediatamente.
Para destruir una conexión, introduzca un comando como el siguiente:

imqcmd destroy cxn -n 2691475382197166336

Utilice los comandos imqcmd list cxn o imqcmd query cxn para obtener el ID de conexión.
Para establecer una propiedad con imqcmd, utilice la nueva opción –D. Es útil para establecer o anular las propiedades de fábrica de la conexión JMS o las propiedades del sistema java relacionadas con la conexión. Por ejemplo:
```
imqcmd list svc -secure -DimqSSLIsHostTrusted=true
imqcmd list svc -secure -Djavax.net.ssl.trustStore=/tmp/mytruststore 
            -Djavax.net.ssl.trustStorePassword=mytrustword
```

Encontrará toda la información sobre la sintaxis del comando imqcmd en el Capítulo 13, Command Line Reference de Sun Java System Message Queue 4.1 Administration Guide.

Compatibilidad con la persistencia de JDBC

Ahora se admite la versión 10.1.1 de Apache Derby como proveedor de almacenes persistentes compatibles con JDBC.

Compatibilidad con SSL

Desde la versión 4.0, el valor predeterminado de la propiedad de fábrica de la conexión del cliente imqSSLIsHostTrusted es false. Si su aplicación depende del valor predeterminado anterior (true), deberá cambiar la configuración y establecer la propiedad explícitamente a true.

Puede elegir si desea confiar en el host cuando el agente está configurado para utilizar certificados autofirmados. En este caso, además de especificar que la conexión debe usar un servicio de conexión basado en SSL (con la propiedad imqConnectionType), debería establecer la propiedad imqSSLIsHostTrusted en verdadera (true).

Por ejemplo, para ejecutar de forma segura las aplicaciones del cliente cuando el agente utiliza certificados autofirmados, utilice un comando como el siguiente:

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true <ClientAppName>

Para ejecutar la herramienta de administración imqcmd de forma segura cuando el agente utiliza certificados autofirmados, utilice un comando como el siguiente:

imqcmd list svc -secure -DimqSSLIsHostTrusted=true

Compatibilidad con JMX

Se ha añadido un nuevo API para configurar y supervisar los agentes de Message Queue de conformidad con la especificación de Java Management Extensions (JMX). Con este API, puede configurar y supervisar las funciones de agente de forma programática desde una aplicación de cliente de Message Queue. En versiones anteriores de Message Queue, sólo era posible acceder a estas funciones desde la línea de comando o desde la consola de administración.

beansI consiste en un conjunto de beans gestionadas (MBeans) que sirven para administrar los siguientes recursos relacionados con Message Queue:

Agentes de mensaje
Servicios de conexión
Conexiones
Destinos
Productores de mensajes
Consumidores de mensajes
Transacciones
Clústeres de agentes
Registros
La máquina virtual de Java (Java Virtual Machine, JVM)

Estas MBeans proporcionan atributos y operaciones para interrogar y manipular de forma síncrona el estado de los recursos subyacentes, y también notificaciones que permiten a una aplicación del cliente escuchar y responder de forma asíncrona a las cambios de estado a medida que se producen. Utilizando JMX API, las aplicaciones del cliente pueden realizar taras de configuración y supervisión como:

Establecer el número de puerto de un agente
Establecer el tamaño máximo de los mensajes de un agente
Detener un servicio de conexión
Establecer el número máximo de subprocesos para un servicio de conexión
Averiguar el número de conexiones actuales que hay en un servicio
Destruir una conexión
Crear un destino
Destruir un destino
Activar o desactivar la creación automática de destinos
Depurar todos los mensajes de un destino
Obtener el número acumulativo de mensajes recibidos por un destino desde que se inició el agente.
Averiguar el estado actual (en ejecución o en pausa) de una cola
Averiguar el número actual de productores de mensajes de un tema
Depurar todos los mensajes de un suscriptor duradero
Averiguar el tamaño de un montón JVM

Encontrará una introducción del API de JMX e información completa de referencia en la Sun Java System Message Queue 4.1 Developer’s Guide for JMX Clients.

Propiedades de compatibilidad del agente relacionadas con JMX

Se han añadido varias propiedades de agente nuevas para admitir el JMX API (consulte la Tabla 1–3). Ninguna de estas propiedades puede configurarse desde la línea de comando con la utilidad Command de Message Queue (imqcmd). Sólo es posible configurarlas con la opción -D de la utilidad Agente (imqbrokerd) o editarlas manualmente en el archivo de configuración de instancias de agente ( config.properties). Además, algunas de estas propiedades (imq.jmx.rmiregistry.start, imq.jmx.rmiregistry.use, imq.jmx.rmiregistry.port) pueden configurarse con las opciones de la utilidad Agente que se describe en la Tabla 1–4. En esta tabla se enumeran todas las opciones, se especifica su tipo y se describe cómo utilizarlas

Tabla 1–3 Nuevas propiedades de agente para la compatibilidad con JMX


Propiedad	Tipo	Descripción
`imq.jmx.rmiregistry.start`	`Boolean`	Especifica si debe iniciarse el registro RMI al iniciarse el agente. truel valor es `true`, el agente iniciará un registro RMI en el puerto especificado por `imq.jmx.rmiregistry.port` y lo utilizará para guardar el cabo RMI de los conectores JMX. imqgjmxnrmiregistry el valor de `imq.jmx.rmiregistry.use` se ignora en este caso. Valor predeterminado: `false`
`imq.jmx.rmiregistry.use`	`Boolean`	Especifica si debe utilizarse un registro RMI. Sólo se cumple si `imq.jmx.rmiregistry.start` es `false`. Si el valor es `true`, el agente utilizará un registro RMI externo en el puerto especificado por `imq.jmx.rmiregistry.port` para guardar el cabo RMI de los conectores JMX. El registro RMI deberá estar ejecutándose ya al iniciarse el agente. Valor predeterminado: `false`
`imq.jmx.rmiregistry.port`	`Integer`	Número de puerto del registro RMI Sólo se cumple si `imq.jmx.rmiregistry.start` o `imq.jmx.rmiregistry.use` son `true`. URL conectores de JMXpueden configurarse después para que utilicen el registro RMI incluyendo este número de puerto en la ruta URL de las URL del servicio JMX. Valor predeterminado: `1099`
`imq.jmx.connector.list`	`String`	Nombres de conectores JMX preconfigurados y separados por comas Valor predeterminado: `jmxrmi,ssljmxrmi`
`imq.jmx.connector.activelist`	`String`	Nombres de conectores JMX que se activarán al iniciarse el agente, separados por comas Valor predeterminado: `jmxrmi`
`imq.jmx.connector.Nombre del conector` `.urlpath`	`String`	El componente`RutaURL` de la URL del servicio JMX para el conector `NombreDelConector` Esto es útil cuando la ruta de la URL del servicio JMX debe configurarse explícitamente (cuando se utiliza un registro externo compartido RMI). Valor predeterminado: Si se utiliza un registro RMI para almacenar el cabo RMI de los conectores de JMX (es decir, si `imq.jmx.registry.start` o `imq.jmx.registry.use` son `true`) /jndi/rmi://`HostDelAgente`:`Puertormi` /`HostDelAgente`/`PuertoDelAgente`/`NombreDelConector` Si no se utiliza un registro RMI (el caso predeterminado `imq.jmx.registry.start` y `imq.jmx.registry.use` ambos `false`): /stub/`Cabormi` donde `Cabormi` es una representacion codificada y serializada del mismo cabo RMI
`imq.jmx.connector.Nombre del conector` `.useSSL`	`Boolean`	Especifica si debe usarse una capa de zócalos seguros (SSL) para el conector `NombreDelConector`. Valor predeterminado: `false`
`imq.jmx.connector.Nombre del conector` `.brokerHostTrusted`	`Boolean`	Especifica si debe confiarse en alguno de los certificados presentados por el agente del conector `NombreDelConector`. Sólo se cumple cuando `imq.jmx.connector.` `NombreDelConector.useSSL` es `true`. Si es `false`, el tiempo de ejecución del cliente de Message Queue validará todos los certificados que se le presenten. La validación fallará si el firmante del certificado no se encuentra en el almacén de confianza del cliente. Si es `true`, se omitirá la validación del certificado. Esto puede ser útil, por ejemplo, durante la fase de pruebas de un software o cuando se utiliza un certificado autofirmado. Valor predeterminado: `false`

La propiedad imq.jmx.connector.list define el conjunto de conectores de JMX con nombre que se crearán al iniciarse el agente, mientras que imq.jmx.connector.activelist especifica cuál de ellos debe activarse. Cada conector con nombre tendrá su propio conjunto de propiedades:

imq.jmx.connector.NombreDelConector .urlpath

imq.jmx.connector.NombreDelConector .useSSL

imq.jmx.connector.NombreDelConector .brokerHostTrusted

Por defecto, se crean dos conectores JMX llamados jmxrmi y ssljmxrmi; el primero está configurado para no utilizar el cifrado SSL (imq.jmx.connector.jmxrmi.useSSL = false, y el segundo, para utilizarlo (imq.jmx.connector.ssljmxrmi.useSSL = true). Por defecto, sólo se activa el conector jmxrmi al iniciarse el agente; consulte Compatibilidad con SSL para los clientes de JMX para conseguir información sobre cómo activar el conector ssljmxrmi y establecer comunicaciones seguras.

Para mayor comodidad, también se han añadido nuevas opciones (Tabla 1–4) a la utilidad Agente de la línea de comando (imqbrokerd) que permiten controlar el uso, el inicio y el puerto del registro RMI. El uso y los efectos de estas opciones son los mismos que los de las propiedades equivalentes del agente, que se describen en la Tabla 1–3. Esta tabla incluye una lista de todas las opciones, especifica la propiedad equivalente del agente y describe cómo se utilizan.

Tabla 1–4 Nuevas opciones de la utilidad Agente para la compatibilidad con JMX


Opción	Propiedad equivalente del agente	Descripción
`-startRmiRegistry`	`imq.jmx.rmiregistry.start`	Especifica si debe iniciarse el registro RMI al iniciarse el agente.
`-useRmiRegistry`	`imq.jmx.rmiregistry.use`	Especifica si debe utilizarse un registro RMI.
`-rmiRegistryPort`	`imq.jmx.rmiregistry.port`	El número de puerto del registroRMI

Se ha añadido un nuevo subcomando (Tabla 1–5) a la utilidad Command de la línea de comando (imqcmd) que enumera las URL del servicio JMX de los conectores JMX creados e iniciados al iniciarse el agente. Esta información la necesitan los clientes de JMX que no utilizan la clase de conveniencia de Message Queue convenience class AdminConnectionFactory para obtener sus conectores JMX; también puede utilizarse pra gestionar o supervisar Message Queue mediante un navegador de JMX genérico como Monitoring and Management Console ( jconsole).

Tabla 1–5 Nuevo subcomando de la utilidad Command


Subcomando	Descripción
`list jmx`	Ofrece una lista de las URL de los conectores JMX del servicio JMX

Compatibilidad con SSL para los clientes de JMX

Como se mencionó más arriba, un agente de mensajes d eMessage Queue está configurado por defecto para establecer comunicaciones no seguras con el conector JMX preconfigurado jmxrmi. Las aplicaciones que deseen utilizar la capa de zócalos seguros (SSL ) para establecer comunicaciones seguras, deberán activar el otro conector JMX seguro: ssljmxrmi. Para ello, debe seguir estos pasos:

Obtenga e instale un certificado firmado de la misma manera que para los servicios de conexión ssljms, ssladmin o cluster, tal y como se describe en la Message Queue Administration Guide.
Instale en el almacén de confianza el certificado raíz de la autoridad de certificación, si es necesario.
Añada el conector ssljmxrmi a la lista de conectores JMX que deben activarse al iniciar el agente:

imq.jmx.connector.activelist=jmxrmi,ssljmxrmi
Inicie el agente con la utilidad Agente de Message Queue ( imqbrokerd), bien facilitándole la contraseña key-store de un archivo de claves, bien escribiéndola desde la línea de comando cuando se le indique.
ssljmxrmito, el conector ssljmxrmi (o cualquier otro conector basado en SSL) está configurado para validar todos los certificados SSL del agente que se le presenten. Si desea evitar esta validación (por ejemplo, cuando utilice certificados autofirmados o durante la prueba de un software), establezca la propiedad del agente imq.jmx.connector.ssljmxrmi.brokerHostTrusted en true.

En el lado del cliente, la fábrica de conexión del administrador (AdminConnectionFactory ) deberá configurarse con una URL que especifique ssljmxrmi como el conector preferido:

AdminConnectionFactory  acf = new AdminConnectionFactory();
acf.setProperty(AdminConnectionConfiguration.imqAddress, "mq://myhost:7676/ssljmxrmi");

Si es preciso, utilice las propiedades del sistema javax.net.ssl.trustStore y javax.net.ssl.trustStorePassword para indicar al cliente de JMX el almacén de confianza.

Registro del tiempo de ejecución del cliente

Esta sección describe la compatibilidad de Message Queue 4.0 con registros de tiempo de ejecución del cliente de sucesos de conexión y eventos relacionados con la sesión

JDK 1.4 (y versiones superiores) incluye la biblioteca java.util.logging. Esta biblioteca implementa una interfaz de registro estándar que puede utilizarse para registros específicos de la aplicación.

El tiempo de ejecución del cliente de Message Queue utiliza Java Logging API para implementar sus funciones de registro. Puede utilizar todos los servicios de registro de J2SE 1.4 para configurar las actividades de registro. Por ejemplo, una aplicación puede utilizar los siguientes servicios de registro de Java para establecer cómo el tiempo de ejecución del cliente de Message Queue debe presentar su información de registro:

Controladores de registro
Filtros de registro
Formateadores de registro
Nivel de registro

Para más información sobre el Java Logging API, consulte la presentación de este producto en http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html

Espacios de nombre de registro, niveles y actividades

El proveedor de Message Queue define un conjunto de espacios de nombre de registro asociados a los niveles de registro y a actividades de registro que permiten a los clientes de Message Queue crear un registro de los sucesos de conexión y de sesión siempre que se haya establecido correctamente la configuración de registro.

El espacio del nombre de registro raíz del tiempo de ejecución de Message Queue está definido como javax.jms. Todos los registros del tiempo de ejecución del cliente de Message Queue utilizan este nombre como espacio de nombres padre.

Los niveles de registro del tiempo de ejecución del cliente de Message Queue son los mismos que los definidos en la clase java.util.logging.Level. Esta clase define siete niveles de registro estándar y dos ajustes adicionales que puede utilizar para desactivar y activar el proceso de registro.

OFF: Desactiva el registro.
SEVERE: Cuanto mayor es la prioridad, más alto es el valor. Definido por la aplicación.
WARNING: Definido por la aplicación.
INFO: Definido por la aplicación.
CONFIG: Definido por la aplicación.
FINE: Definido por la aplicación.
FINER: Definido por la aplicación.
FINEST: Cuanto menor es la prioridad, menor es el valor. Definido por la aplicación.
ALL: Activa el registro de todos los mensajes.

En general, las excepciones y los errores que se producen en el tiempo de ejecución del cliente de Message Queue son registrados con el espacio de nombre javax.jms.

Las excepciones que devuelve JVM y que capta el tiempo de ejecución del cliente, como IOException, quedan registradas con el espacio de nombre de registro javax.jms en el nivel WARNING.
Las excepciones de JMS que devuelve el tiempo de ejecución del cliente, como IllegalStateException , quedan registradas con el espacio de nombre de registro javax.jms en el nivel FINER.
Los errores que devuelve JVM y que capta el tiempo de ejecución del cliente, como OutOfMemoryError, quedan registrados con el espacio de nombre de registro javax.jms en el nivel SEVERE.

La siguiente tabla muestra una lista de los sucesos que pueden registrarse y el nivel de registro que debe establecerse en los sucesos de registro para las conexiones de JMS y las sesiones.

La siguiente tabla describe los niveles de registro y los sucesos de conexiones.

Tabla 1–6 Niveles de registro y sucesos para el espacio de nombre javax.jms.connection


Nivel de registro	Sucesos
`FINE`	Conexión creada
`FINE`	Conexión iniciada
`FINE`	Conexión cerrada
`FINE`	Conexión interrumpida
`FINE`	Conexión reanudada
`FINER`	Diversas actividades de conexión como `setClientID`
`FINEST`	Mensajes, reconocimientos, mensajes de acción y control de Message Queue (como confirmar una transacción)

Para las sesiones, se deja constancia de la siguiente información en el registro.

Cada registro de un mensaje entregado a un consumidor incluye el ID de la conexión, el ID de la sesión y el ID del consumidor.
Cada registro de un mensaje enviado por un productor incluye el ID de la conexión, el ID de la sesión y el ID del productor, además del nombre del destino.

La siguiente tabla describe los niveles de registro y los sucesos de las sesiones.

Tabla 1–7 Niveles de registro y sucesos para el espacio de nombre javax.jms.session


Nivel de registro	Suceso
`FINE`	Sesión creada
`FINE`	Sesión cerrada
`FINE`	Productor creado
`FINE`	Consumidor creado
`FINE`	Destino creado
`FINER`	Diversas actividades de sesión como confirmar una sesión.
`FINEST`	Mensajes producidos y consumidos. (Las propiedades y los cuerpos de los mensajes no se consignan en los registros.)

Por defecto, el nivel de registro de salida se hereda del JRE en que se esté ejecutando la aplicación. Compruebe el archivo JRE_DIRECTORY/lib/logging.properties para determinar cuál es el nivel.

Puede configurar el registro de forma programática o mediante archivos de configuración, de forma que pueda controlar el ámbito en que se produce el registro. En las siguientes secciones se describen estas posibilidades.

Mediante el archivo de configuración de registro JRE

El siguiente ejemplo muestra cómo establecer espacios de nombre y niveles de registro en el archivo JRE_DIRECTORY/lib/logging.properties, que se utiliza para establecer el nivel de registro del entorno en tiempo de ejecución de Java. Todas las aplicaciones que utilicen este JRE tendrán la misma configuración de registro. El ejemplo de configuración que se muestra abajo establece el nivel de registro en INFO para el espacio de nombre javax.jms.connection y especifica que la salida debe escribirse en java.util.logging.ConsoleHandler .

#registro.archivo de propiedades.
# "controladores" especifica una lista separada por comas de clases
# de controladores de registro. Estos controladores se instalan durante el inicio de VM.
# Tenga en cuenta que estas clases deberán estar en la ruta de clase del sistema.
# Por defecto, solo configuramos un ConsoleHandler, que sólo mostrará
# mensajes en el nivel INFO y superiores.

	controladores= java.util.logging.ConsoleHandler

# Nivel de registro global predeterminado.
# Especifica qué tipo de sucesos se registran en todos los
# registros. Es posible anular este nivel global para un recurso 
# determinado y sustituirlo por un nivel específico para el recurso.
# Observe que el ConsoleHandler también tiene una configuración de nivel
# independiente para limitar los mensajes que se imprimen en la consola.

    .nivel= INFO

#Limitar los mensajes que se imprimen en la consola a INFO y niveles superiores.

    java.util.logging.ConsoleHandler.level = INFO
    java.util.logging.ConsoleHandler.formatter = 
                                    java.util.logging.SimpleFormatter

# Este registro con espacio de nombre de conexión javax.jms. escribirá
# mensajes de nivel INFO en sus controladores de salida. En esta configuración 
# el controlador de entrada está establecido en java.util.logging.ConsoleHandler.

    javax.jms.connection.level = INFO

Utilizar un archivo de configuración de registro para una aplicación específica

También puede definir un archivo de configuración de registro desde la línea de comandos de Java que utiliza para ejecutar una aplicación. La aplicación utilizará la configuración definida en el archivo de registro especificado. En el siguiente ejemplo, configFile utiliza el mismo formato definido en el archivo JRE_DIRECTORY/lib/logging.properties .

java -Djava.util.logging.config.file=configFile MQApplication

Establecer la configuración de registro de forma programática

El siguiente código utiliza el API java.util.logging para registrar sucesos de conexión y lo hace cambiando el nivel del espacio de nombre javax.jms.connection a FINE. Puede incluir este código en su aplicación para establecer la configuración de registro de forma programática.

import java.util.logging.*;
//construye un controlador de archivo y una salida en el archivo mq.log  
//del directorio temp del sistema.

    Handler fh = new FileHandler("%t/mq.log");
    fh.setLevel (Level.FINE);

//Obtener registrador para el dominio  "javax.jms.connection".

    Logger logger = Logger.getLogger("javax.jms.connection");
    logger.addHandler (fh);

//el registrador javax.jms.connection registraría las actividades 
//de nivel FINE y superior.

    logger.setLevel (Level.FINE);

Notificación de sucesos de conexión

Las notificaciones de los sucesos de conexión permiten al cliente de Message Queue escuchar los sucesos de cierre y reconexión, y tomar las medidas oportunas en función del tipo de notificación y del estado de conexión. Por ejemplo, si se produce un error y el cliente se vuelve a conectar a otro agente, es posible que una aplicación quiera limpiar el estado de su transacción y proceder con una nueva.

Si el proveedor de Message Queue detecta un problema grave con una conexión, invocará a la escucha de excepción registrada del objeto de conexión. Llama al método onException y le envía un argumento JMSException que describe el problema. El proveedor de Message Queue también ofrece un API de notificación de sucesos que permite al tiempo de ejecución del cliente informar a la aplicación sobre los cambios que se produzcan en el estado de la conexión. El API de notificación se define por los siguientes elementos:

El paquete com.sun.messaging.jms.notification, que define la escucha de sucesos y los objetos de suceso de notificaciones.
La interfaz com.sun.messaging.jms.Connection, que define las extensiones de la interfaz javax.jms.Connection.

Las siguientes secciones describen los eventos que pueden desencadenar una notificación y explican cómo crear una escucha de sucesos.

Sucesos de conexión

La siguiente tabla muestra una lista de los sucesos que puede devolver la escucha de sucesos.

Tenga en cuenta que la escucha de excepción de JMS no se invoca cuando se produce un suceso de conexión. La escucha de excepciones sólo se invoca cuando el tiempo de ejecución del cliente ha agotado sus intentos de reconexión. El tiempo de ejecución del cliente siempre invoca la escucha de sucesos antes que la escucha de excepciones.

Tabla 1–8 Sucesos de notificación


Tipo de suceso	Significado
`ConnectionClosingEvent`	El tiempo de ejecución del cliente de Message Queue genera este suceso cuando el agente le notifica que está a punto de cerrarse una conexión debido a que el administrador ha solicitado el cierre.
`ConnectionClosedEvent`	El tiempo de ejecución del cliente de Message Queue genera este suceso cuando se cierra una conexión debido a un error del agente o porque el administrador haya solicitado cerrarla o reiniciarla. Cuando una escucha de sucesos recibe un `ConnectionClosedEvent,`, la aplicación puede utilizar el método `getEventCode()` del suceso recibido para obtener un código de sucesos que especifique la causa del cierre.
`ConnectionReconnectedEvent`	El tiempo de ejecución del cliente de Message Queue ha vuelto a conectar con un agente. Este agente podría ser el mismo con el que el cliente estaba conectado antes u otro diferente. Una aplicación puede utilizar el método `getBrokerAddress` del suceso recibido para obtener la dirección del agente con el que ha vuelto a establecer conexión.
`ConnectionReconnectFailedEvent`	El tiempo de ejecución del cliente de Message Queue no ha conseguido reconectar con un agente. Siempre que un intento de reconexión falla, el tiempo de conexión genera un nuevo suceso y lo transmite a la escucha de sucesos. La escucha de excepción de JMS no se invoca cuando se produce un suceso de conexión. Sólo se invoca cuando el tiempo de ejecución del cliente ha agotado sus intentos de reconexión. El tiempo de ejecución del cliente siempre invoca la escucha de sucesos antes que la escucha de excepciones.

Crear una escucha de sucesos

El siguiente código de ejemplo muestra cómo establecer una escucha de sucesos de conexión. Siempre que se produce un suceso de conexión, el tiempo de ejecución del cliente invocará el método onEvent de la escucha del suceso.

//crear una fábrica de conexión de MQ.

com.sun.messaging.ConnectionFactory factory =
        new com.sun.messaging.ConnectionFactory();

//crear una conexión de MQ.

com.sun.messaging.jms.Connection connection = 
       (com.sun.messaging.jms.Connection )factory.createConnection();

//construir una escucha de sucesos de MQ.  La escucha implementa 
//com.sun.messaging.jms.notification.EventListener interface.

com.sun.messaging.jms.notification.EventListener eListener = 
       new ApplicationEventListener();

//establecer una escucha de sucesos en la conexión MQ.

connection.setEventListener ( eListener );

Ejemplos de escuchas de sucesos

En este ejemplo, una aplicación elige ordenar a su escucha de sucesos que registre el evento de conexión en el sistema de registro de la aplicación:

public class ApplicationEventListener implements
				com.sun.messaging.jms.notification.EventListener {

vacío público onEvent ( com.sun.messaging.jms.notification.Event connEvent ) {
      	registro (connEvent);
}
registro de vacío privado ( com.sun.messaging.jms.notification.Event connEvent ) {
	      String eventCode = connEvent.getEventCode(); 
      	String eventMessage = connEvent.getEventMessage();
    	  //escribir información de eventos en el flujo de salida.
     	}
}

Requisitos de hardware y software

Para conocer los requisitos de hardware y software de la versión 4.0, consulte las notas de la versión de Sun Java System Application Server Platform Edition 9.