Broker Compatibility

A Message Queue 4.3 message broker will interoperate with one from Versions 3.0.x, 3.5, 3.6, or 3.7, and is able to migrate data from Versions 3.6 or 3.7. However, some changes have been made in broker properties and the persistent store schema. The degree of compatibility depends on the earlier Message Queue version from which you are upgrading:

• Message Queue 3.7 data is fully compatible with Message Queue 4.3 and requires no data migration.

• Message Queue 3.6 data is generally compatible with Message Queue 4.3 and requires no data migration.

• Data from Message Queue 3.5 must be migrated by upgrading to Message Queue 3.6 or later before installing Message Queue 4.3.

When upgrading from Message Queue 3.6 or 3.7 to Message Queue 4.3, you can choose either of two approaches to handling the older versions’ instance configuration (config.properties) files:

• Use the older config.properties files directly.

• Copy the files to another location and consult the property settings they contain when you configure Message Queue 4.3 brokers.

Any persistent Message Queue 3.6 or 3.7 data (messages, destinations, and durable subscriptions) is automatically converted to Message Queue 4.3 data when starting up a Message Queue 4.3 broker for the first time. For example, existing destinations will be converted to Message Queue 4.3 destinations, preserving existing attributes and using default values for new attributes.

For Message Queue 3.6, the automatic upgrade leaves the original data intact in its original location. You can delete this data in either of the following ways:

• Use the Broker utility’s -upgrade-store-nobackup option when starting up the Message Queue 4.3 broker for the first time:

     imqbrokerd  -upgrade-store-nobackup
  

• Manually delete the old file-based persistent data store, located at

     …/instances/instanceName/fs350
  

If you mix Message Queue 3.5, 3.6, or 3.7 brokers together with Message Queue 4.3 brokers in a cluster, you should consider the following issues:

• Mixed broker versions. A conventional cluster can contain brokers of different versions if all brokers have a version at least as great as that of the master broker. If the cluster is not configured to use a master broker, then all brokers must be of the same version.

• Matching broker property values. In addition to cluster configuration properties, the following broker properties also must have the same value for all brokers in a cluster:

  • imq.service.activelist

  • imq.autocreate.queue

  • imq.autocreate.topic

  • imq.autocreate.queue.maxNumActiveConsumers

  • imq.autocreate.queue.maxNumBackupConsumers

  This restriction is particularly important when a cluster contains mixed broker versions that might contain properties with different default values. For example, If you are clustering a Message Queue version 4.3 broker together with versions 3.x, you must set the value of the imq.autocreate.queue.maxNumActiveConsumers property, which has different default values before and after version 4.1 (1 and -1, respectively), to be the same. Otherwise the brokers will not be able to establish a cluster connection.

When upgrading a broker cluster from versions 3.x to versions 4.x, it is recommended that you shut down all client applications and all brokers in the cluster, perform the Message Queue upgrades, check any data migrations, and then restart the cluster and client applications. It is not recommended that you attempt a rolling upgrade in which you successively upgrade brokers while maintaining messaging operations.