The following issues affect broker clusters.
Only fully-connected broker clusters are supported in this release. This means that every broker in a cluster must communicate directly with every other broker in the cluster. If you are connecting brokers into a conventional cluster using the imqbrokerd -cluster command line argument, be careful to ensure that all brokers in the cluster are included.
If a client is connected to a broker in a high-availability broker cluster, the client runtime will attempt to reconnect until it succeeds (it ignores the value of the imqAddressListIterations connection factory attribute.)
A client can only browse the contents of queues that are located on its home broker. The client can still send messages to any queue or consume messages from any queue in the cluster; the limitation only affects queue browsing.
In a conventional cluster that includes version 4.2 brokers, all brokers must be version 3.5 or later.
Message Queue 4.2 and 4.1 brokers cannot interoperate in a cluster by default with Message Queue 3.7 or 3.6 brokers because the default value of imq.autocreate.queue.maxNumActiveConsumers changed between these versions. (Bug 6716400)
WorkaroundChange the value of the Message Queue 4.2 and 4.1 brokers' imq.autocreate.queue.maxNumActiveConsumers from the default value of -1 to the previous version's default value of 1.
When converting from a conventional cluster to a high-availability cluster, you can use the Message QueueDatabase Manager utility (imqdbmgr) to convert an existing standalone JDBC—based data store to a shared high-availability data store as documented in Converting a Standalone Data Store to a Shared Data Store in Sun Java System Message Queue 4.2 Administration Guide
A broker using HADB cannot handle messages larger than 10 MB. (Bug 6531734)
The conversion to an HADB store using the command imqdbmgr upgrade hastore can fail with the message “too many locks are set” if the store holds more than 10,000 message. (Bug 6588856)
WorkaroundUse the following command to increase the number of locks.
hadbm set NumberOfLocks=<desiredNumber>
For additional information see “HADB Problems” in Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.
If more than 500 remote messages are committed in one transaction, the broker might return the error “HADB-E-12815: Table memory space exhausted.” (Bug 6550483)
For additional information, see “HADB Problems” in Sun Java System Application Server 9.1 Enterprise Edition Troubleshooting Guide.
In a broker cluster, a broker will queue messages to a remote connection that has not been started. (Bug 4951010)
Workaround: The messages will be received by the consumer once the connection is started. The messages will be redelivered to another consumer if the consumer’s connection is closed.
When consuming more than one message from a remote broker in one transaction, it is possible that the following error message will be logged to the broker. The message is benign and can be ignored:
[26/Jul/2007:13:18:27 PDT] WARNING [B2117]: Message acknowledgement failed from mq://126.96.36.199:7677/?instName=a&brokerSessionUID=3209681167602264320: ackStatus = NOT_FOUND(404)\ Reason = Update remote transaction state to COMMITED(6): transaction 3534784765719091968 not found, the transaction may have already been committed. AckType = MSG_CONSUMED MessageBrokerSession = 3209681167602264320 TransactionID = 3534784765719091968 SysMessageID = 8-188.8.131.52(95:fd:93:91:ec:a0)-33220-1185481094690 ConsumerUID = 3534784765719133952\par [26/Jul/2007:13:18:27 PDT] WARNING Notify commit transaction [8-184.108.40.206(95:fd:93:91:ec:a0)-33220-1185481094690, [consumer:3534784765719133952, type=NONE]] TUID=3534784765719091968 got response: com.sun.messaging.jmq.jmsserver.util.BrokerException: Update remote transaction state to COMMITED(6): transaction 3534784765719091968 not found, the transaction may have already been committed.: com.sun.messaging.jmq.jmsserver.util.BrokerException: Update remote transaction state to COMMITED(6): transaction 3534784765719091968 not found, the transaction may have already been committed.r
This message gets logged when notifying the commit to the message home broker for later messages in the transaction when the imq.txn.reapLimit property is low compared to the number of remote messages in one transaction. (Bug 6585449)
Workaround: To avoid this message increase the value of the imq.txn.reapLimit property.