Broker Clusters

The following issues affect broker clusters.

• High-availability broker with MySQL Cluster datastore fails to restart if abnormally terminated (Bug 6896877)

  Workaround: This issue is caused by a known issue in MySQL Cluster (http://bugs.mysql.com/bug.php?id=47955). A correction for this issue has been pushed to MySQL versions 5.1.39-ndb-6.3.28, 5.1.39-ndb-7.0.9 and 5.1.39-ndb-7.1.0.

• 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 an enhanced 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.3 brokers, all brokers must be version 3.5 or later.

• Message Queue 4.3, 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)

  Workaround: Make sure all brokers have the same value of Change the value of imq.autocreate.queue.maxNumActiveConsumers, usually accomplished by changing the Message Queue 4.3, 4.2, and 4.1 configuration to match that used by the 3.7 or 3.6 brokers (by default, from the value of -1 to the previous version's default value of 1).

• To add a Message Queue 4.3 (or 4.x) broker to a Message Queue 3.x broker cluster, the a master broker must be running. (Bug 6763796)

• When converting from a conventional cluster to an enhanced cluster, you can use the Message Queue Database Manager utility (imqdbmgr) to convert an existing standalone JDBC-based data store to a shared JDBC data store as documented in Cluster Conversion: JDBC-Based Data Store in Sun GlassFish Message Queue 4.4 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 opened. (Bug 4951010)

  Workaround: The messages will be received by the consumer once the connection is opened. The messages will be redelivered to another consumer if the consumer’s connection remains 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://129.145.130.95: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-129.145.130.95(95:fd:93:91:ec:a0)-33220-1185481094690
          ConsumerUID = 3534784765719133952\par
  
  [26/Jul/2007:13:18:27 PDT] WARNING Notify commit transaction 
  [8-129.145.130.95(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.