Topic host routing in publish/subscribe clusters

Publications from non-hosting queue managers in the cluster are routed through the hosting queue manager to any queue manager in the cluster with a matching subscription.

For an introduction to how messages are routed between queue managers in publish/subscribe hierarchies and clusters, see Distributed publish/subscribe networks.

To understand the behavior and benefits of topic host routing it is best to first understand Direct routing in publish/subscribe clusters.

A topic host routed publish/subscribe cluster behaves as follows:
  • Clustered administered topic objects are manually defined on individual queue managers in the cluster. These are referred to as topic host queue managers.
  • When a subscription is made on a cluster queue manager, channels are created from the subscription host queue manager to the topic host queue managers, and proxy subscriptions are created only on the queue managers that host the topic.
  • When an application publishes information to a topic, the connected queue manager always forwards the publication to one queue manager that hosts the topic, which passes it on to all queue managers in the cluster that have matching subscriptions to the topic.

This process is explained in more detail in the following examples.

Topic host routing using a single topic host

For publications to flow between queue managers in a topic host routed cluster, you cluster a branch of the topic tree as described in Configuring a publish/subscribe cluster, and specify topic host routing.

There are a number of reasons to define a topic host routed topic object on multiple queue managers in a cluster. However, for simplicity we start with a single topic host.

The following diagram shows a queue manager cluster that is not currently used for publish/subscribe or point-to-point activities. Note that every queue manager in the cluster connects only to and from the full repository queue managers.

Figure 1. A queue manager cluster
A cluster is shown containing a number of queue managers. Two of the queue managers are full repositories, and know everything about the activities of the cluster. All the other queue managers in the cluster are connected by channels to the full repositories.

In a topic host routed publish/subscribe cluster, you define the topic object on a specific queue manager in the cluster. Publish/subscribe traffic then flows through that queue manager, making it a critical queue manager in the cluster and increasing its workload. For these reasons it is not recommended to use a full repository queue manager, but to use another queue manager in the cluster. When you define the topic object on the host queue manager, knowledge of the object and its host is automatically pushed, by the full repository queue managers, to all the other queue managers in the cluster. Note that, unlike direct routing, each queue manager is not told about every other queue manager in the cluster.

Figure 2. A topic host routed publish/subscribe cluster with one topic defined on one topic host
A cluster is shown containing a number of queue managers, including two full repositories. A topic is defined on a queue manager that is not a full repository. All other queue managers in the cluster know about the topic and its host queue manager.

When a subscription is created on a queue manager, a channel is created between the subscribing queue manager and the topic host queue manager. The subscribing queue manager connects only to the topic host queue manager, and sends details of the subscription (in the form of a proxy subscription). The topic host queue manager does not forward this subscription information on to any further queue managers in the cluster.

Figure 3. A topic host routed publish/subscribe cluster with one topic defined on one topic host, and one subscriber
A cluster is shown containing a number of queue managers, including two full repositories. A topic is defined on a queue manager that is not a full repository. Another queue manager hosts a subscription to the topic. There is a channel between the subscription host and the topic host, and the topic host knows about the subscription.

When a publishing application connects to another queue manager and a message is published, a channel is created between the publishing queue manager and the topic host queue manager, and the message is forwarded to that queue manager. The publishing queue manager has no knowledge of any subscriptions on other queue managers in the cluster, so the message is forwarded to the topic host queue manager even if there are no subscribers to that topic in the cluster. The publishing queue manager connects only to the topic host queue manager. Publications are routed through the topic host to the subscribing queue managers, if any exist.

Subscriptions on the same queue manager as the publisher are satisfied directly, without first sending the messages to a topic host queue manager.

Note that, because of the critical role played by each topic host queue manager, you must choose queue managers that can handle the load, availability and connectivity requirements of topic hosting.

Figure 4. A topic host routed publish/subscribe cluster with one topic, one subscriber and one publisher
A cluster is shown containing a number of queue managers, including two full repositories. A topic is defined on a queue manager that is not a full repository. Another queue manager hosts a subscription to the topic, and a third queue manager has received a publication. There is a channel from the publishing queue manager to the topic host, and another from the topic host to the subscribing queue manager. The publication is routed through the topic host to the subscribing queue manager.

Dividing the topic tree across multiple queue managers

A routed topic hosting queue manager is only responsible for the subscription knowledge and publication messages that relate to the branch of the topic tree that its administered topic object is configured for. If different topics are used by different publish/subscribe applications in the cluster, you can configure different queue managers to host different clustered branches of the topic tree. This allows scaling by reducing the publication traffic, subscription knowledge and channels on each topic host queue manager in the cluster. You should use this method for distinct high volume branches of the topic tree:

Figure 5. A topic host routed publish/subscribe cluster with two topics, each defined on one topic host
A cluster is shown containing a number of queue managers, including two full repositories. Two topics are defined, each on a different queue manager that is not a full repository. Other queue managers host publications and subscriptions to the two topic, and each publication is routed through the matching topic host to the subscribing queue managers.

For example, using the topics described in Topic trees, if topic T1 was configured with a topic string of /USA/Alabama, and topic T2 was configured with a topic string of /USA/Alaska, then a message published to /USA/Alabama/Mobile would be routed through the queue manager hosting T1, and a message published to /USA/Alaska/Juneau would be routed through the queue manager hosting T2.

Note: You cannot make a single subscription span multiple clustered branches of the topic tree by using a wildcard higher in the topic tree than the points that are clustered. See Wildcard subscriptions.

Topic host routing using multiple topic hosts for a single topic

If a single queue manager has the responsibility for the routing of a topic, and that queue manager becomes unavailable or incapable of handling the workload, publications will not flow promptly to the subscriptions.

If you need greater resiliency, scalability and workload balancing than you get when you define a topic on just one queue manager, you can define a topic on more than one queue manager. Each individual message published is routed through a single topic host. When multiple matching topic host definitions exist, one of the topic hosts is chosen. The choice is made in the same way as for clustered queues. This allows messages to be routed to available topic hosts, avoiding any that are unavailable, and allows message load to be workload balanced across multiple topic host queue managers and channels. However, ordering across multiple messages is not maintained when you use multiple topic hosts for the same topic in the cluster.

The following diagram shows a topic host routed cluster in which the same topic has been defined on two queue managers. In this example, the subscribing queue managers send information about the subscribed topic to both topic host queue managers in the form of a proxy subscription:

Figure 6. Creating proxy subscriptions in a multiple topic host publish/subscribe cluster
A cluster is shown containing a number of queue managers, including two full repositories. A topic is defined on two queue managers that are not full repositories. Two other queue managers host subscriptions, and each subscribing queue manager is shown sending proxy subscriptions to both the topic host queue managers.

When a publication is made from a non-hosting queue manager, the queue manager sends a copy of the publication to one of the topic host queue managers for that topic. The system chooses the host based on the default behavior of the cluster workload management algorithm. In a typical system, this approximates to a round-robin distribution across each topic host queue manager. There is no affinity between messages from the same publishing application; this equates to using a cluster bind type of NOTFIXED.

Figure 7. Receiving publications in a multiple topic host publish/subscribe cluster
A cluster is shown containing a number of queue managers, including two full repositories. A topic is defined on two queue managers that are not full repositories. Two other queue managers host subscriptions. A publication is received on another queue manager, and the publishing queue manager is shown sending the publication to one of the topic host queue managers.

Inbound publications to the chosen topic host queue manager are then forwarded to all queue managers that have registered a matching proxy subscription:

Figure 8. Routing publications to subscribers in a multiple topic host publish/subscribe cluster
A cluster is shown containing a number of queue managers, including two full repositories. A topic is defined on two queue managers that are not full repositories. Two other queue managers host subscriptions. A publication is received on another queue manager, and the publishing queue manager is shown sending the publication to one of the topic host queue managers. The topic host then sends a copy of the publication to all the subscribers to the topic.

Making subscriptions and publishers local to a topic host queue manager

The above examples show the routing between publishers and subscribers on queue managers that do not host administered routed topic objects. In these topologies, messages require multiple hops to reach the subscriptions.

Where the additional hop is not desirable, it might be appropriate to connect key publishers to topic hosting queue managers. However, if there are multiple topic hosts for a topic and only one publisher, all publication traffic will be routed through the topic host queue manager that the publisher is connected to.

Similarly, if there are key subscriptions, these could be located on a topic host queue manager. However, if there are multiple hosts of the routed topic, only a proportion of the publications will avoid the additional hop, with the remainder being routed through the other topic host queue managers first.

Topologies such as these are described further here: Topic host routing using centralized publishers or subscribers.

Note: Special planning is needed if changing the routed topic configuration when co-locating publishers or subscriptions with routed topic hosts. For example, see Adding extra topic hosts to a topic host routed cluster.

Summary and additional considerations

A topic host routed publish/subscribe cluster gives you precise control over which queue managers host each topic, and those queue managers become the routing queue managers for that branch of the topic tree. Moreover, queue managers without subscriptions or publishers have no need to connect with the topic host queue managers, and queue managers with subscriptions have no need to connect to queue managers that do not host a topic. This configuration can significantly reduce the number of connections between queue managers in the cluster, and the amount of information being passed between queue managers. This is especially true in large clusters where only a subset of queue managers are performing publish/subscribe work. This configuration also gives you some control over the load on individual queue managers in the cluster, so (for example) you can choose to host highly active topics on more powerful and more resilient systems. For certain configurations - notably larger clusters - it is usually a more appropriate topology than direct routing.

However, topic host routing also imposes certain constraints upon your system:
  • System configuration and maintenance require more planning than for direct routing. You need to decide which points to cluster in the topic tree, and the location of the topic definitions in the cluster.
  • Just as for direct routed topics, when a new topic host routed topic is defined, the information is pushed to the full repository queue managers, and from there direct to all members of the cluster. This event causes channels to be started to each member of the cluster from the full repositories if not already started.
  • Publications are always sent to a host queue manager from a non-host queue manager, even if there are no subscriptions in the cluster. Therefore, you should use routed topics when subscriptions are typically expected to exist, or when the overhead of global connectivity and knowledge is greater than the risk of extra publication traffic.
    Note: As previously described, making publishers local to a topic host can mitigate this risk.
  • Messages that are published on non-host queue managers do not go direct to the queue manager that hosts the subscription, they are always routed through a topic host queue manager. This approach can increase the total overhead to the cluster, and increase message latency and reduce performance.
    Note: As previously described, making subscriptions or publishers local to a topic host can mitigate this risk.
  • Using a single topic host queue manager introduces a single point of failure for all messages that are published to a topic. You can remove this single point of failure by defining multiple topic hosts. However, having multiple hosts affects the order of published messages as received by subscriptions.
  • Extra message load is incurred by topic host queue managers, because publication traffic from multiple queue managers needs to be processed by them. This load can be lessened: Either use multiple topic hosts for a single topic (in which case message ordering is not maintained), or use different queue managers to host routed topics for different branches of the topic tree.

Before you use topic host routing, explore the alternative approaches detailed in Direct routing in publish/subscribe clusters, and Routing in publish/subscribe hierarchies.