Broker Issues

The following issues affect the Message Queue broker.

• Message Queue 4.4 clients receive an unclear warning when connecting to Message Queue 3.7 brokers (Bug 6899886)

  When a Message Queue 4.4 client connects to a Message Queue 3.7 broker, the client receives a warning of the form:

  WARNING [I500]: Caught JVM exception: ... 
  [C4036]: A broker error occurred. :[505] bad version ...

  This “bad version” warning indicates that the client should reconnect to the broker at a lower protocol level.

• 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 Enhanced Clusters: JDBC Configuration Properties in Sun GlassFish Message Queue 4.4 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)

• When using IBM JVM on AIX, broker sometimes runs into low or RED memory condition without apparent reason (Bug 6899526)

  Workaround: Use the latest version of the IBM JVM (Java Runtime 1.6.0 IBM Corporation or higher) and pass the following IBM JVM GC option to imqbrokerd:

  # imqbrokerd -vmargs -Xgcpolicy:gencon