Los problemas siguientes afectan al agente de Message Queue.
Los clientes de Message Queue 4.4 reciben una advertencia poco clara al conectarse con agentes de Message Queue 3.7 (Error 6899886)
Cuando un cliente de Message Queue 4.4 se conecta a un agente de Message Queue 3.7, el cliente recibe una advertencia de tipo:
WARNING [I500]: Caught JVM exception: ... [C4036]: A broker error occurred. :[505] bad version ...
Esta advertencia de “versión incorrecta” indica que el cliente debe conectarse al agente con un nivel de protocolo inferior.
Al utilizar un almacén de datos JDBC, la contraseña de la base de datos se almacena como texto visible (Error 6691717)
Solución: proteger el archivo de contraseña que contiene la contraseña de la base, tal y como se describe en Password Files de Sun GlassFish Message Queue 4.4 Administration Guide.
No se puede tener acceso al agente cuando un almacén de datos persistente abre demasiados destinos. (Fallo 4953354)
Solución: Esta situación se produce cuando el agente alcanza el límite de descriptor de archivos abiertos del sistema. En Solaris y Linux utilice la orden ulimit para incrementar el límite del descriptor de archivos.
Cuando se destruye un destino, los consumidores se quedan sin referencia. ( Fallo 5060787)
Los consumidores activos se quedan sin referencia cuando se destruye un destino. En ese caso, dejan de recibir mensajes (aunque se vuelva a crear el destino).
Cuando un cliente JMS que utiliza servicio de conexión HTTP finaliza de forma abrupta (por ejemplo por el uso de Ctrl-C), el agente tarda aproximadamente un minuto en liberar la conexión del cliente y todos los recursos asociados.
Si se inicia otra instancia del cliente dentro de este periodo de un minuto y si ésta intenta utilizar el mismo ClientID, la misma suscripción duradera o cola, es posible que se genere la excepción "ID de cliente ya en uso". No se trata de un problema real, es simplemente un efecto secundario del proceso de finalización descrito anteriormente. Si el cliente se inicia después de un retraso de aproximadamente un minuto, todo debería funcionar correctamente.
Al utilizar la base de datos MySQL para un almacén de datos, los mensajes almacenados de más de 1 MB generarán una excepción SQL “El paquete de la consulta es demasiado grande...". (Fallo 6682815)
Solución: Inicie el servidor MySQL con la opción --max_allowed_packet establecida en un valor mayor que 1 MB, el tamaño predeterminado. Por ejemplo, utilice el siguiente valor:
--max_allowed_packet=60M
Al utilizar la base de datos MySQL para un almacén de datos compartido de alta disponibilidad, se necesita un mecanismo para configurar el motor de almacenamiento MySQL como NDBCLUSTER . (Fallo 6691394)
Solución: Añada la siguiente propiedad al archivo config.properties del agente (consulte la sección Enhanced Clusters: JDBC Configuration Properties de Sun GlassFish Message Queue 4.4 Administration Guide)
imq.persist.jdbc.mysql.tableoption=EMGINE=NDBCLUSTER
Si utiliza el controlador 9i de Oracle (JDBC 9.2.0.x), el agente genera la excepción "Fallo al definir propiedad como persistente...”. (Fallo 6626825)
Solución: Utilice el controlador 10g de Oracle (JDBC 10.2.0.x), para el que el agente está optimizado.
imq.persist.jdbc.derby.table.MYCONSTATE41.index.IDX2=CREATE INDEX &(index) ON $(name) (MESSAAGE_ID)
Cuando utilice la base de datos Java DB para un almacén de datos, al almacenar un mensaje se generará la excepción SQL “no se ha podido obtener un bloqueo en el tiempo solicitado”. (Fallo 6691394)
Solución: Añada el siguiente valor de propiedad al archivo config.properties del agente::
imq.persist.jdbc.derby.table.MYCONSTATE41.index.IDX2=CREATE INDEX &(index) ON $(name) (MESSAAGE_ID)
Al utilizar IBM JVM en AIX, el agente puede entrar en condición de memoria baja o RED sin motivo aparente (Error 6899526)
Solución: utilice la versión más reciente de JVM IBM (Java Runtime 1.6.0 IBM Corporation o superior) y envíe la siguiente opción de IBM JVM GC a imqbrokerd:
# imqbrokerd -vmargs -Xgcpolicy:gencon |