Message Queue 4.0 es una versión secundaria que se limita a ser compatible con Application Server 9 PE. Incluía algunas nuevas funciones, algunas mejoras relacionadas con las funciones y soluciones a fallos. Esta sección incluye una descripción de las nuevas funciones de esta versión:
Uno de los cambios más insignificantes que incorporaba la versión 4.0, pero que puede provocar interrupciones, era la anulación de la opción de línea de comandos para especificar una contraseña. De ahora en adelante, debe guardar todas las contraseñas en un archivo tal y como se describe en Opción de contraseña eliminada, o introducirlas cuando se le soliciten.
Se ha añadido una nueva API a Message Queue 4.0 para configurar y supervisar los agentes de Message Queue de acuerdo con la especificación Java Management Extensions (JMX). Con esta API, puede configurar y supervisar las funciones de agente de forma práctica desde una aplicación Java. En versiones anteriores de Message Queue, sólo era posible acceder a estas funciones desde las utilidades de administración de línea de comando o la consola de administración.
Si necesita más información, consulte la Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients .
Message Queue 4.0 incluía compatibilidad con el registro de conexión del tiempo de ejecución del cliente y eventos relacionados con las sesiones.
Para obtener más información sobre el registro del tiempo de ejecución del cliente y cómo configurarlo, consulte la página 137 de la Guía para desarrolladores de Java.
Message Queue 4.0 incluía una API de notificación de sucesos que permitía que el tiempo de ejecución de cliente informase a una aplicación sobre los cambios en el estado de la 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 continuar con una nueva.
Para obtener información acerca de los eventos de conexión y sobre cómo crear un receptor de eventos, consulte la página 96 de la Guía para desarrolladores de Java.
En Message Queue 4.0, se añadieron varias opciones de comando y un nuevo subcomando a la utilidad Command (imqcmd) para permitir a los administradores desactivar un agente, cerrar un agente tras un intervalo específico, destruir una conexión o establecer propiedades del sistema java (por ejemplo, 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 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 una agrupación de agentes mejorada.
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 16, Command Line Reference de Sun GlassFish Message Queue 4.4 Administration Guide.
En Message Queue 4.0 se añadió un nuevo subcomando query a la utilidad Database Manager, imqdbmgr. Este subcomando se utiliza para mostrar información sobre el almacén de datos basado en JDBC, como la versión de la base de datos, el usuario de la base de datos y si se han creado las tablas de la base 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] Using plugged-in persistent store: version=400 brokerid=Mozart1756 database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb database user=scott Running in standalone mode. Database tables have already been created. |
En Message Queue 4.0, Apache Derby Version 10.1.1 ya es compatible como proveedor de almacén de datos basado en JDBC.
Message Queue 4.0 introdujo cambios en el almacén de datos basado en JDBC para optimizar el sistema y permitir mejoras en el futuro. Por este motivo, el formato del almacén de datos basado en JDBC se amplió a la versión 400. Tenga en cuenta que en Message Queue 4.0, la versión del almacén de datos basado en archivos sigue siendo la 370, porque no se ha realizado ningún cambio.
Message Queue 4.0 añadió dos nuevas propiedades que están configuradas en todos los mensajes ubicados 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.
Desde la versión Message Queue 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 en 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 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 utilizar la utilidad Comando (imqcmd) de forma segura cuando el agente utiliza certificados autofirmados, utilice un comando como el siguiente (para enumerar los servicios del conector).
imqcmd list svc -secure -DimqSSLIsHostTrusted=true