Agrupaciones de agentes (Sun GlassFish Message Queue 4.4 Update 1

Sun GlassFish Message Queue 4.4 Update 1 - Notas de la version

Agrupaciones de agentes

Los siguientes problemas afectan a las agrupaciones de agentes.

Agente de alta disponibilidad con almacén de datos MySQL Cluster no puede reiniciarse si se finalizó de manera inapropiada (Error 6896877)

Solución: Este problema lo provoca un problema conocido de MySQL Cluster (http://bugs.mysql.com/bug.php?id=47955). Se ha aplicado una corrección de este problema a las versiones de MySQL 5.1.39-ndb-6.3.28 , 5.1.39-ndb-7.0.9 y 5.1.39-ndb-7.1.0.
En esta versión, sólo se admiten agrupaciones de agentes totalmente conectadas. Esto significa que todos los agentes de una agrupación deben comunicarse directamente con todos los demás agentes de la agrupación. Si se conecta a agentes de una agrupación convencional mediante el argumento de línea de comandos imqbrokerd -cluster, asegúrese de que se incluyen todos los agentes del clúster.
Si un cliente se conecta a un agente de una agrupación de agentes mejorada, el tiempo de ejecución del cliente intentará reconectar hasta que lo consiga (ignora el valor del atributo de fábrica de conexión imqAddressListIterations.)
Un cliente sólo podrá examinar el contenido de las colas que estén ubicadas en su agente local. El cliente puede continuar enviando mensajes a cualquier cola o consumiendo mensajes desde una cola de cualquier agrupación; esta limitación sólo afecta a las funciones de exploración de colas.
En una agrupación convencional que incluya agentes de la versión 4.3, todos los agentes deben ser de la versión 3.5 o posterior.
Los agentes de Message Queue 4.3, 4.2 y 4.1 no pueden interoperar en una agrupación de forma predeterminada con agentes de Message Queue 3.7 o 3.6, dado que el valor predeterminado de imq.autocreate.queue.maxNumActiveConsumers se ha modificado entre estas versiones. (Fallo 6716400)

Solución: Asegúrese de que todos los agentes tienen el mismo valor para la opción imq.autocreate.queue.maxNumActiveConsumers, normalmente, puede cambiar la configuración de Message Queue 4.3, 4.2 y 4.1 para que coincida con la que se usan los agentes de las versiones 3.7 y 3.6 (cambie el valor predeterminado -1 al valor de la versión anterior: 1).
Para añadir un agente de Message Queue 4.3 (o 4.x) a una agrupación de agentes de Message Queue 3.x, el agente principal debe estar ejecutándose. (Fallo 6763796)
Al convertir una agrupación convencional en una mejorada, puede usar la herramienta de administración de bases de datos de Message Queue (imqdbmgr ) para convertir un almacén de datos basado en JDBC independiente en un almacén de datos basado en JDBC compartido, como se explica en la sección Cluster Conversion: JDBC-Based Data Store de Sun GlassFish Message Queue 4.4 Administration Guide
Un agente que utilice HADB no puede gestionar mensajes superiores a 10 MB. (Fallo 6531734)
La conversión a un almacén HADB con el comando imqdbmgr upgrade hastore puede fallar y generar el mensaje "hay demasiados bloqueos establecidos" si el almacén contiene más de 10.000 mensajes. (Fallo 6588856)

Solución: Utilice el siguiente comando para aumentar el número de bloqueos.

hadbm set NumberOfLocks=<número>

Para más información, consulte "Problemas de HADB" en la Guía de resolución de problemas de Sun Java System Application Server 9.1 Enterprise Edition.
Si se confirman más de 500 mensajes remotos en una transacción, el agente podría devolver el error "HADB-E-12815: Espacio de memoria de tabla agotado.” (Fallo 6550483)

Para más información, consulte "Problemas de HADB" en la Guía de resolución de problemas de Sun Java System Application Server 9.1 Enterprise Edition.
En una agrupación de agentes, el agente coloca mensajes en la cola para una conexión remota que no se ha abierto. (Fallo 4951010)

Solución: El consumidor recibirá los mensajes cuando se abra la conexión. Los mensajes se enviarán a otro consumidor si la conexión con el consumidor sigue cerrada.

Al consumir más de un mensaje de un agente remoto en una transacción, es posible que se registre en el agente el siguiente mensaje de error. El mensaje es benigno y puede omitirse:

[26/Jul/2007:13:18:27 PDT] WARNING [B2117]: 
Message acknowledgement failed from 
mq://129.145.130.95:7677/?instName=a&brokerSessionUID=3209681167602264320:
    ackStatus = NOT_FOUND(404)\
    Reason = Update remote transaction state to COMMITED(6): 
transaction 3534784765719091968 not found, the transaction
may have already been committed.
    AckType = MSG_CONSUMED
    MessageBrokerSession = 3209681167602264320
    TransactionID = 3534784765719091968
        SysMessageID = 8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690
        ConsumerUID = 3534784765719133952\par

[26/Jul/2007:13:18:27 PDT] WARNING Notify commit transaction 
[8-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690, 
[consumer:3534784765719133952, type=NONE]]
TUID=3534784765719091968 got response: 
com.sun.messaging.jmq.jmsserver.util.BrokerException:
 Update remote transaction state to COMMITED(6): 
  transaction 3534784765719091968 not found, the transaction may have already 
  been committed.:
com.sun.messaging.jmq.jmsserver.util.BrokerException: Update remote transaction 
state to COMMITED(6): transaction 3534784765719091968 not found, the transaction
 may have already been committed.r

El mensaje se registra al notificar la confirmación al agente de inicio del mensaje para posteriores mensajes de la transacción cuando la propiedad imq.txn.reapLimit es baja comparada con el número de mensajes remotos de una transacción. (Fallo 6585449)

Solución: Para evitar este mensaje, aumente el valor de la propiedad imq.txn.reapLimit.