Nuevas funciones de Información de resolución de problemas de 4.2 y versiones recientes

Las nuevas funciones de Información de resolución de problemas de 4.2, 4.2 y 4.0 se describen en las siguientes secciones:

• Nuevas funciones de Información de resolución de problemas de 4.2

• Nuevas funciones de Información de resolución de problemas de 4.1

• Nuevas funciones de Información de resolución de problemas de 4.0

Nuevas funciones de Información de resolución de problemas de 4.2

Sun Java System Información de resolución de problemas de es un servicio de mensajería completo que proporciona funciones fiables y asíncronas, conformes con la especificación Java Messaging Specification (JMS) 1.1. Además, Información de resolución de problemas de incluye funciones que superan la especificación JMS para dar satisfacción a las necesidades de las instalaciones en grandes empresas.

Información de resolución de problemas de 4.2 es una versión menor que incluye nuevas mejoras en lo que a funciones y soluciones a fallos se refiere. Esta sección explica cómo instalar o realizar una actualización a Información de resolución de problemas de 4.2 y describe las nuevas funciones que se incluyen en esta versión:

• Varios destinos para un editor o suscriptor

• Validación de esquemas de mensajes de datos útiles XML

• Compatibilidad C-API con transacciones distribuidas

• Compatibilidad del instalador con el Registro de conexiones Sun

• Compatibilidad con la base de datos MySQL

Para obtener información sobre las funciones que se incluyen en Información de resolución de problemas de 4.0 y 4.1, consulte Nuevas funciones de Información de resolución de problemas de 4.0 y Nuevas funciones de Información de resolución de problemas de 4.1, respectivamente.

Varios destinos para un editor o suscriptor

En Información de resolución de problemas de 4.2, un editor puede publicar mensajes en varios destinos de temas y un suscriptor puede consumir mensajes procedentes de varios destinos de temas. Esta función se logra al utilizar un nombre de destino de temas que incluye caracteres comodín que representen varios destinos. Al utilizar dichos nombres simbólicos, los administradores pueden crear destinos de temas adicionales, según sea necesario, coherentes con el esquema de asignación de nombres comodín. Los editores y suscriptores publican y consumen automáticamente a partir de los destinos añadidos. (Los suscriptores de los temas comodín son más comunes que los editores.)

Esta función no se aplica a destinos de cola.

El formato del nombre de destino de temas simbólico consta de varios segmentos, en los que los caracteres comodín (*, **, >) pueden representar uno o más segmentos del nombre. Por ejemplo, suponga que tiene el siguiente esquema de asignación de nombres de destinos de temas:

size.color. shape

en el que los segmentos del nombre del tema pueden tener los siguientes valores:

• size: large, medium, small, ...

• color: red, green, blue, ...

• shape: circle, triangle, square, ...

Message Queue admite los siguientes caracteres comodín:

• * hace coincidir un único segmento

• ** hace coincidir uno o más segmentos

• > hace coincidir cualquier número de segmentos sucesivos

Por lo tanto, puede indicar varios destinos de temas de la siguiente manera:

large.*.circle representaría:

large.red.circle
large.green.circle
...

**.square representaría todos los nombres que acaban en .square , por ejemplo:

small.green.square
medium.blue.square
...

small.> representaría todos los nombres de destinos que comienzan por small., por ejemplo:

small.blue.circle
small.red.square
...

Para utilizar esta función de destinos múltiples, deberá crear destinos de temas utilizando un esquema de asignación de nombres similar al descrito anteriormente. A continuación, las aplicaciones de cliente pueden crear editores o consumidores utilizando nombres de destinos simbólicos. Por ejemplo:

...
String DEST_LOOKUP_NAME = "large.*.circle";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicPublisher myPublisher = mySession.createPublisher(t)
myPublisher.send(myMessage);

...
String DEST_LOOKUP_NAME = "**.square";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicSubscriber mySubscriber = mySession.createSubscriber(t);
Message m = mySubscriber.receive();

En el primer ejemplo, el agente colocará una copia del mensaje en cualquier destino que coincida con el nombre simbólico large.*.circle. En el segundo ejemplo, se creará un suscriptor si existe al menos un destino que coincida con el nombre simbólico **.square y recibirá mensajes de todos los destinos que coincidan con dicho nombre simbólico. Si no existen destinos que coincidan con el nombre simbólico, el suscriptor no se creará hasta que exista dicho destino.

Si un administrador crea destinos adicionales que coincidan con un nombre simbólico, los editores comodín creados mediante dicho nombre simbólico se publicarán en dicho destino y los editores comodín creados mediante dicho nombre simbólico recibirán mensajes de dicho destino.

Además, las herramientas de administración de Message Queue, aparte de realizar informes acerca del número total de editores (productores) y suscriptores (consumidores) de un destino de temas, también realizarán informes sobre el número de editores que son editores comodín (incluidos sus nombres de destino simbólicos correspondientes) y el número de suscriptores que son suscriptores comodín (incluidos sus nombres de destino simbólicos), si es que existen.

Validación de esquemas de mensajes de datos útiles XML

Esta nueva función de Información de resolución de problemas de 4.2 permite la validación del contenido de un mensaje de texto (no un objeto) XML contra un esquema XML en el momento en el que se envía el mensaje al agente. La ubicación del esquema XML (XSD) se especifica como propiedad de un destino de Message Queue. Si no se especifica ninguna ubicación XSD, la declaración DTD del documento XML se utilizará para realizar la validación DTD. (la validación XSD, que incluye la validación del intervalo de valor y el tipo de datos, es más rigurosa que la validación DTD.)

Las aplicaciones cliente que utilizan esta nueva función deben actualizarse desde la versión Java SE a JRE 1.5 o superior.

Para activar la validación del esquema XML, se deben configurar las siguientes propiedades de destinos físicos:

Al activar la validación XML, el tiempo de ejecución del cliente de Información de resolución de problemas de intentará validar un mensaje XML contra los XSD especificados (o contra el DTD, si no se especifica el XSD) antes de enviarlo al agente. Si el esquema especificado no puede ubicarse o el mensaje no puede validarse, el mensaje no se enviará, y se lanzará una excepción.

Las propiedades de la validación XML se pueden configurar en el momento de la creación del destino o en el momento de la actualización a través de los comandos imqcmd create dst o imqcmd update dst, respectivamente. Las propiedades de la validación XML deben configurarse cuando el destino esté inactivo: es decir, cuando no cuente con consumidores o productores, y cuando no haya mensajes en el destino.

Si no se puede acceder a un XSD durante el tiempo de ejecución, es posible que sea necesario modificar XMLSchemaURIList mientras esté activo el destino.

Si alguna de las propiedades de la validación XML se configura mientras que un destino está activo (por ejemplo, si un productor está conectado al destino), el cambio no tendrá lugar hasta que el productor se vuelva a conectar al agente. De igual forma, si se modifica un XSD, como resultado de la modificación de los requisitos de la aplicación, todas las aplicaciones cliente que produzcan mensajes XML basados en el XSD modificado deberán reconectarse al agente.

Si la propiedad reloadXMLSchemaOnFailure está configurada en true y la validación XML no se realiza de la forma correcta, el tiempo de ejecución del cliente de Información de resolución de problemas de intentará recargar el XSD antes de volver a intentar validar un mensaje. El tiempo de ejecución del cliente lanzará una excepción si la validación no se realiza correctamente al utilizar el SXD recargado.

Compatibilidad C-API con transacciones distribuidas

Según el modelo de transacciones distribuidas X/Open, la compatibilidad con transacciones distribuidas se basa en un administrador de transacciones distribuidas que supervisa y administra las operaciones que realizan uno o más administradores de recursos. En Información de resolución de problemas de 4.2, la C-API de Message Queue es compatible con la interfaz XA (entre un administrador de transacciones distribuidas y Message Queue como administrador de recursos compatibles con XA), lo que permite a los clientes de C-API de Message Queue funcionar en un entorno de procesamiento de transacciones distribuidas (tales como BEA Tuxedo) con el fin de participar en transacciones distribuidas.

Esta compatibilidad con transacciones distribuidas cuenta con las siguientes nuevas funciones de C-API (y nuevos parámetros y códigos de error) que se utilizan para implementar la especificación de la interfaz XA:

MQGetXAConnection()
MQCreateXASession()

Si la aplicación de un cliente de C se va a utilizar en el contexto de una transacción distribuida, debe obtener una conexión a través de MQGetXAConnection() y crear una sesión para producir y consumir mensajes mediante MQCreateXASession(). . El inicio, la confirmación y la anulación de cualquier transacción distribuida se administra a través de API suministradas a través del administrador de transacciones distribuidas.

Información pública

La especificación de la interfaz XA de X/Open requiere la siguiente información pública con respecto al administrador de recursos compatibles con XA de Message Queue:

• Nombre de la estructura xa_switch_t: sun_my_xa_switch

• Nombre del Administrador de recursos: SUN_RM

• La biblioteca C-API de MQ que se va a establecer como vínculo: mqcrt

• La cadena xa_close y el formato: none

• La cadena xa_open y el formato: nombre separado por “;”=pares de valores

Los siguientes pares de valores/nombre son compatibles:

Ejemplos de programación

Para programar una aplicación que utilice transacciones distribuidas, crea un servicio del lado del servidor que se ejecuta en el entorno del administrador de transacciones y el código del lado del cliente que llama a las API del administrador de transacciones. Message Queue 4.2 incluye ejemplos de programación basados en el administrador de transacciones de Tuxedo. Estos ejemplos están ubicados en el directorio de programas de ejemplo de cada plataforma dentro del directorio ./C/tuxedo.

Este directorio incluye un archivo README que explica cómo configurar Tuxedo para utilizar el administrador de recursos de Message Queue y cómo crear los siguientes programas de ejemplo en el entorno de Tuxedo:

Compatibilidad del instalador con el Registro de conexiones Sun

El instalador de Message Queue se ha mejorado para permitir el registro de Message Queue con Sun Connection, un servicio del sistema Sun que le ayuda a supervisar, organizar y mantener software y hardware de Sun.

Como parte de la instalación de Message Queue, puede elegir registrar Message Queue con Sun Connection. La información acerca del Message Queue instalado, como por ejemplo la versión, el nombre del sistema, el sistema operativo, la fecha de instalación y otra información básica se transmite de forma segura a la base de datos de Sun Connection. El servicio de inventario de Sun Connection puede ayudarle a organizar su hardware y software de Sun, mientras que el servicio de actualización puede informarle de las últimas soluciones de seguridad disponibles, actualizaciones recomendadas y mejoras con respecto a las funciones.

La siguiente pantalla del instalador se ha añadido a Información de resolución de problemas de 4.2 para el registro en Sun Connection:

El registro requiere que cuente con una cuenta Sun Online o que cree una. Si aún no tiene una cuenta, el instalador le proporcionará la siguiente pantalla para crear una cuenta Sun Online:

Puede registrar Message Queue durante la instalación utilizando las pantallas anteriores, o esperar a que la instalación finalice y ejecutar el instalador en el modo de sólo registro, de la siguiente manera:

# installer -r

El modo de sólo registro requiere que Información de resolución de problemas de 4.2 ya esté instalado y únicamente mostrará las pantallas del instalador relacionadas con el registro.

Compatibilidad con la base de datos MySQL

Información de resolución de problemas de 4.2 es compatible con la base de datos MySQL como almacén de datos basado en JDBC. MySQL Cluster Edition puede utilizarse como base de datos JDBC en el caso de un agente independiente, y MySQL Cluster Edition puede utilizarse como el almacén de datos compartido altamente disponible necesario para obtener un clúster de agente de alta disponibilidad. Para obtener información acerca de cómo configurar Información de resolución de problemas de para utilizar MySQL, consulte Configuring a JDBC-Based Data Store de Sun Java System Message Queue 4.2 Administration Guide así como High-Availability Cluster Properties de Sun Java System Message Queue 4.2 Administration Guide.

Nuevas funciones de Información de resolución de problemas de 4.1

Información de resolución de problemas de 4.1 fue una versión menor que incluía nuevas funciones, mejoras relacionadas con las funciones y soluciones a fallos. Esta sección describe las nuevas funciones de la versión 4.1 y le ofrece más referencias para su uso:

• Clústeres de agente de alta disponibilidad

• Compatibilidad con JAAS

• Cambio del formato del almacén de datos persistente

• Configuración del entorno del agente

• Compatibilidad con Java ES Monitoring Framework

• Administración de transacciones mejorada

• Puertos fijos para las conexiones de los clientes C

Para conseguir información sobre las funciones nuevas de Message Queue 4.0, consulte Nuevas funciones de Información de resolución de problemas de 4.0.

Clústeres de agente de alta disponibilidad

Información de resolución de problemas de 4.1 ha introducido clústeres de agente de alta disponibilidad. En comparación con los clústeres de agente convencionales, que sólo ofrecen disponibilidad de servicio de mensajería (si un agente tiene algún problema, hay otro agente disponible para ofrecer el servicio de mensajería), los clústeres de agente de alta disponibilidad también incluyen disponibilidad de datos (si un agente tiene algún problema, están disponibles sus mensajes persistentes y sus datos de estado para que otro agente lo utilice con el fin de hacerse cargo de la entrega de mensajes).

La implementación de alta disponibilidad que se incluye en Información de resolución de problemas de 4.1 utiliza un almacén de datos basado en JDBC: en lugar de tener cada agente de un clúster de agente su propio almacén de datos persistente, todos los agentes del clúster comparten la misma base de datos compatible con JDBC. Si un agente en particular tiene algún error, otro agente del clúster asume el enrutamiento y la entrega del mensaje del agente del fallo. Al hacer esto, el agente del error utiliza datos e información sobre el estado en el almacén de datos compartido. Los clientes de mensajería del agente que ha causado el error se reconectan a dicho agente, que ofrece un servicio de mensajería sin interrupciones.

El almacén compartido basado en JDBC utilizado en la implementación de alta disponibilidad de Información de resolución de problemas de 4.1 debe ser de por sí altamente disponible. Si no cuenta con una base de datos altamente disponible o si la entrega de mensajes ininterrumpida no le resulta importante, puede continuar utilizando clústeres convencionales, que ofrecen disponibilidad de servicios sin disponibilidad de datos.

Para configurar un clúster de agente altamente disponible de Información de resolución de problemas de 4.1, debe especificar las siguientes propiedades del agente en cada agente del clúster:

• Propiedades de pertenencia a clúster, que sirven para especificar si el agente forma parte de un clúster de agente de alta disponibilidad, el ID del clúster y el ID del agente del clúster.

• Propiedades de la base de datos altamente disponible, que especifican el modelo de datos persistentes (JDBC), el nombre del proveedor de la base de datos y las propiedades de configuración específicas del proveedor.

• Detección de fallos y propiedades de error, que especifica cómo se detecta el fallo del agente y cómo se administra mediante un agente de error.

Para utilizar la implementación del clúster de agente de alta disponibilidad, debe hacer lo siguiente:

1. Instalar una base de datos de alta disponibilidad.

2. Instalar el archivo .jar del controlador de JDBC.

3. Crear el esquema de la base de datos para el almacén de datos persistente de alta disponibilidad.

4. Establecer propiedades de alta disponibilidad para cada agente del clúster.

5. Iniciar cada uno de los agentes del clúster.

Si desea consultar una explicación del concepto de clústeres de agente de alta disponibilidad y una comparación con los clústeres convencionales, consulte el Capítulo 4, Broker Clusters de Sun Java System Message Queue 4.2 Technical Overview. Si desea información sobre procedimientos y referencias de los clústeres de agente de alta disponibilidad, consulte el Capítulo 10, Configuring and Managing Broker Clusters de Sun Java System Message Queue 4.2 Administration Guide y Cluster Configuration Properties de Sun Java System Message Queue 4.2 Administration Guide.

Si ha estado utilizando una base de datos de alta disponibilidad con Información de resolución de problemas de 4.0 y desea cambiar a un clúster de agente de alta disponibilidad, puede utilizar la utilidad Administrador de bases de datos (imqdbmgr para pasarse a un almacén de datos persistente compartido. De igual forma, consulte Clústeres de agente para conocer más problemas y limitaciones.

Compatibilidad con JAAS

Además de los mecanismos de autenticación basados en archivos y en LDAP que integra, Información de resolución de problemas de 4.1 también es compatible con Java Authentication y Authorization Service (JAAS), que le permite conectar un mecanismo de autenticación externo al agente para autenticar los clientes de Message Queue.

Para obtener una descripción de la información que un agente pone a su disposición en un servicio de autenticación compatible con JAAS y una explicación acerca de cómo configurar el agente para utilizar dicho servicio, consulte Using JAAS-Based Authentication de Sun Java System Message Queue 4.2 Administration Guide.

Cambio del formato del almacén de datos persistente

Información de resolución de problemas de 4.1 modificó el almacén de datos basado en JDBC para dar soporte a clústeres de agente de alta disponibilidad. Por esta razón, el formato del almacén de datos basado en JDBC ha aumentado a la versión 410. Las versiones de los formatos 350, 370 y 400 migran automáticamente a la versión 410.

Tenga en cuenta que el formato del almacén de datos persistente basado en archivos permanece en la versión 370 dado que no se realizaron cambios en el mismo.

Configuración del entorno del agente

La propiedad IMQ_DEFAULT_EXT_JARS se ha añadido al archivo de configuración del entorno de Información de resolución de problemas de 4.1, imqenv.conf. Puede configurar esta propiedad para especificar el nombre de las rutas de los archivos .jar que deben incluirse en CLASSPATH al iniciarse el agente. Si utiliza esta propiedad para especificar la ubicación de los archivos .jar externos, ya no necesitará copiar estos archivos en el directorio lib/ext. Los archivos .jar externos pueden hacer referencia a los controladores de JDBC o a módulos de registro JAAS. La siguiente propiedad de ejemplo especifica la ubicación de los controladores JDBC.

IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar

Compatibilidad con Java ES Monitoring Framework

Información de resolución de problemas de 4.1 ha incluido la compatibilidad con Sun Java Enterprise System (Java ES) Monitoring Framework, que permite controlar los componentes de Java ES mediante una interfaz gráfica común. La interfaz se implementa mediante una consola basada en web llamada "Sun Java System Monitoring Console". Los administradores pueden utilizar la Consola para ver las estadísticas de rendimiento, crear reglas para realizar un control automático y alarmas de confirmación. Si ejecuta Message Queue junto con otros componentes de Java ES, le resultará más cómodo gestionar todos los componentes con una única interfaz.

Para obtener más información sobre cómo utilizar la función Java ES Monitoring Framework para controlar Message Queue, consulte XREF.

Administración de transacciones mejorada

Anteriormente, los administradores sólo podían deshacer transacciones que estuvieran en estado PREPARED Es decir, si una sesión que formara parte de una transacción distribuida no terminaba correctamente, la transacción permanecía en un estado que era imposible reorganizar para el administrador. En Información de resolución de problemas de 4.1, puede utilizar la utilidad Comando (imqcmd) para reorganizar (deshacer) transacciones que se encuentran en los siguientes estados: STARTED, FAILED, INCOMPLETE, COMPLETE y PREPARED.

Para ayudarle a determinar si es posible deshacer una transacción particular (sobre todo si no se encuentra en estado PREPARED), la utilidad Comando proporciona datos adicionales como parte de la salida imqcmd query txn: proporciona el ID de la conexión que inició la transacción y especifica la hora en la que se creó la transacción. Basándose en esta información, el administrador puede decidir si es preciso deshacer o no la transacción. Por lo general, el administrador debe evitar deshacer una transacción prematuramente.

Puertos fijos para las conexiones de los clientes C

En Información de resolución de problemas de 4.1, los clientes de C, como los clientes Java, pueden conectarse a un puerto de agente fijo en lugar de a un puerto asignado dinámicamente por el servicio Port Mapper del agente. Las conexiones a puertos fijos son útiles si intenta utilizar un servidor de seguridad o si necesita omitir el servicio Port Mapper por alguna otra razón.

Para configurar una conexión a puerto fija, debe configurar el agente y el tiempo de ejecución del cliente de C (ambos extremos de la conexión). Por ejemplo, si desea conectar a su cliente con el puerto 1756 mediante ssljms, tendría que hacer lo siguiente:

• En el lado del cliente, establezca las siguientes propiedades:

  MQ_SERVICE_PORT_PROPERTY=1756

  MQ_CONNECTION_TYPE_PROPERTY=SSL

• En el lado del agente, establezca la propiedad imq.serviceName.protocolType .port de la siguiente manera:

  imq.ssljms.tls.port=1756

La propiedad de conexión MQ_SERVICE_PORT_PROPERTY ha pasado al puerto anterior de Message Queue 3.7 Update 2.

Nuevas funciones de Información de resolución de problemas de 4.0

Información de resolución de problemas de 4.0 fue una versión menor que se limitaba 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:

• Compatibilidad con el API de administración JMX

• Registro del tiempo de ejecución del cliente

• API de notificación de sucesos de conexión

• Mejoras en la administración del agente

• Información sobre el almacén de datos basado en JDBC

• Compatibilidad con el proveedor de JDBC

• Cambios en el formato del almacén de datos persistente.

• Propiedades de mensajes adicionales

• Compatibilidad con SSL

Uno de los cambios más insignificantes que incorporaba la versión 4.0, pero que puede provocar interrupciones, era la desaprobación de la opción command-line 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 desaprobada, o introducirlas cuando se le soliciten.

Compatibilidad con el API de administración JMX

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

Para obtener más información consulte la Sun Java System Message Queue 4.2 Developer’s Guide for JMX Clients.

Registro del tiempo de ejecución del cliente

Información de resolución de problemas de 4.0 incluyó la 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 en relación al registro del tiempo de ejecución del cliente y a cómo configurarlo, consulte la pág. 137 de la Guía de Java Dev.

API de notificación de sucesos de conexión

Información de resolución de problemas de 4.0 incluyó una API de notificación de sucesos que permite que el tiempo de ejecución de cliente informe a una aplicación sobre los cambios en el estado 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.

Para obtener información acerca de los eventos de conexión y sobre cómo crear un receptor de eventos, consulte la pág. 96 de la Guía de Java Dev.

Mejoras en la administración del agente

En Información de resolución de problemas de 4.0, se añadieron varias opciones de comando y un nuevo subcomando a la utilidad Comando (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 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 agente 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 15, Command Line Reference de Sun Java System Message Queue 4.2 Administration Guide.

Información sobre el almacén de datos basado en JDBC

En Información de resolución de problemas de 4.0 se añadió un nuevo subcomando query a la utilidad Administrador de bases de datos, 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] 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.

Compatibilidad con el proveedor de JDBC

En Información de resolución de problemas de 4.0, Apache Derby Version 10.1.1 ya es compatible como proveedor de almacén de datos basado en JDBC.

Cambios en el formato del almacén de datos persistente.

Información de resolución de problemas de 4.0 introdujo cambios en el almacén de datos basado en JDBC para obtener optimización y para dar soporte a futuras mejoras. Por esta razón el formato del almacén de datos basado en JDBC aumentó 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 permanece en 370 dado que no se han realizado cambios. .

Propiedades de mensajes adicionales

Información de resolución de problemas de 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.

Compatibilidad con SSL

Desde la versión Información de resolución de problemas de 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 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