The following issues affect the Message Queue broker.
Broker becomes inaccessible when persistent data store opens too many destinations. (Bug 4953354)
Workaround: This condition is caused by the broker reaching the system open-file descriptor limit. On Solaris and Linux use the ulimit command to increase the file descriptor limit.
Consumers are orphaned when a destination is destroyed. (Bug 5060787)
Active consumers are orphaned when a destination is destroyed. Once the consumers have been orphaned, they will no longer receive messages (even if the destination is recreated).
When a JMS client using the HTTP connection service terminates abruptly (for example, using Ctrl-C) the broker takes approximately one minute before releasing the client connection and all the associated resources.
If another instance of the client is started within the one minute period and if it tries to use the same ClientID, durable subscription, or queue, it might receive a “Client ID is already in use” exception. This is not a real problem; it is just the side effect of the termination process described above. If the client is started after a delay of approximately one minute, everything should work fine.
When using MySQL database for a data store, storing messages greater than 1 MB throw a “Packet for query is too large...” SQLException. (Bug 6682815)
Workaround: Start the MySQL server with the --max_allowed_packet option set to a value greater than the 1 MB default. For example, use the following value:
--max_allowed_packet=60M
When using MySQL database for a highly-available shared data store, a mechanism is needed to configure the MySQL storage engine as NDBCLUSTER. (Bug 6691394)
Workaround: Add the following property value to the broker's config.properties file (see High-Availability Clusters: JDBC Configuration Properties in Sun Java System Message Queue 4.3 Administration Guide)
imq.persist.jdbc.mysql.tableoption=EMGINE=NDBCLUSTER
When using Oracle's 9i (JDBC 9.2.0.x) driver, broker throws “Failed to persist property...” exception. (Bug 6626825)
Workaround: Use Oracle's 10g (JDBC 10.2.0.x) driver, for which the broker is optimized.
imq.persist.jdbc.derby.table.MYCONSTATE41.index.IDX2=CREATE INDEX &(index) ON $(name) (MESSAAGE_ID)
When using Java DB database for a data store, storing a message throws a “lock could not be obtained within the time requested” SQLException. (Bug 6691394)
Workaround: Add the following property value to the broker's config.properties file::
imq.persist.jdbc.derby.table.MYCONSTATE41.index.IDX2=CREATE INDEX &(index) ON $(name) (MESSAAGE_ID)