Broker Issues (Oracle GlassFish Message Queue 4.4.2 Release Notes)

Oracle GlassFish Message Queue 4.4.2 Release Notes

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.
When using a JDBC data store, the database password is stored in clear text (Bug 6691717)

Workaround: Secure the password file containing the database password as described in Password Files in Oracle GlassFish Message Queue 4.4.2 Administration Guide.
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 Cluster Edition database for a data store, the error log for MySQL Cluster Edition shows a “logging of table ./mqdb/MQCREC41Ca with BLOB attribute and no PK is not supported. (Bug 6925362)

Workaround: Define a primary key of the CREATE_TS column for the MQCREC41 table in default.properties:

imq.persist.jdbc.mysql.table.MQCREC41=\
        CREATE TABLE ${name} (\
                RECORD MEDIUMBLOB NOT NULL,\
                CREATED_TS BIGINT NOT NULL,\
                PRIMARY KEY(CREATED_TS)) ${tableoption}

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 Oracle GlassFish Message Queue 4.4.2 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