Broker Clusters

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.

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.