Problemas de agentes

Los problemas siguientes afectan al agente de Message Queue.

• 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)