Publish/subscribe and multiple clusters

A single queue manager can be a member of more than one cluster. This arrangement is sometimes known as overlapping clusters. Through such an overlap, clustered queues can be made accessible from multiple clusters, and point-to-point message traffic can be routed from queue managers in one cluster to queue managers in another cluster. Clustered topics in publish/subscribe clusters do not provide the same capability. Therefore, their behavior must be clearly understood when using multiple clusters.

Unlike for a queue, we cannot associate a topic definition with more than one cluster. The scope of a clustered topic is confined to those queue managers in the same cluster as the topic is defined for. This allows publications to be propagated to subscriptions only on those queue managers in the same cluster.

A queue manager's topic tree

When a queue manager is a member of multiple clusters it is made aware of all clustered topics defined in each of those clusters. For example, in the previous figure QM3 is aware of both the T _B and T _C administered clustered topic objects, whereas QM1 is only aware of T _B. QM3 applies both topic definitions to its local topic, and therefore has a different behavor to QM1 for certain topics. For this reason it is important that clustered topics from different clusters do not interfere with each other. Interference can occur when one clustered topic is defined above or below another clustered topic in a different cluster (for example, they have topic strings of /Sport and /Sport/Football) or even for the same topic string in both. Another form of interference is when administered clustered topic objects are defined with the same object name in different clusters, but for different topic strings.

If such a configuration is made, the delivery of publications to matching subscriptions becomes very dependent on the relative locations of publishers and subscribers with respect to the cluster. For this reason, we cannot rely on such a configuration, and we should change it to remove the interfering topics.

When planning an overlapping cluster topology with publish/subscribe messaging, we can avoid any interference by treating the topic tree and clustered topic object names as if they span all overlapping clusters in the topology.

Integrating multiple publish/subscribe clusters

If there is a requirement for publish/subscribe messaging to span queue managers in different clusters, there are two options available:

• Connect the clusters together through the use of a publish/subscribe hierarchy configuration. See Combining the topic spaces of multiple clusters.
• Create an additional cluster that overlays the existing clusters and includes all queue managers that need to publish or subscribe to a particular topic.

With the latter option, we should consider carefully the size of the cluster and the most effective cluster routing mechanism. SeeDesigning publish/subscribe clusters. Parent topic: Designing publish/subscribe clusters