A topic host routed publish/subscribe cluster gives you precise control over which queue managers host each topic. These topic hosts 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 hosts. This configuration can significantly reduce the number of connections between queue managers in the cluster, and the amount of information that is passed between queue managers.
A topic host routed publish/subscribe cluster behaves as follows:
Topics are manually defined on individual topic host queue managers in the cluster.
When a subscription is made on a cluster queue manager, proxy subscriptions are created only on the topic hosts.
When an application publishes information to a topic, the receiving queue manager forwards the publication to a queue manager that hosts the topic. The topic host then sends the publication to all queue managers in the cluster that have valid subscriptions to the topic.
For many configurations, topic host routing is a more appropriate topology than direct routing because it provides the following benefits:
Improved scalability of larger clusters. Only the topic host queue managers need to be able to connect to all other queue managers in the cluster. Therefore, there are fewer channels between queue managers, and there is less inter-queue manager publish/subscribe administrative traffic than for direct routing. When subscriptions change on a queue manager, only the topic host queue managers need to be informed.
More control over the physical configuration. With direct routing, all queue managers assume all roles, and therefore all need to be equally capable. With topic host routing, you explicitly choose the topic host queue managers. Therefore, you can ensure that those queue managers are running on adequate equipment, and you can use less powerful systems for the other queue managers.
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.
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.
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.
Topic host routing with centralized publishers or subscribers
To remove the extra "hop" incurred when publications are always routed to subscriptions through a topic host queue manager, configure the publishers or the subscriptions on the same queue manager that hosts the topic. This approach brings maximum performance benefits in the following two cases:
Topics with many publishers and few subscriptions. In this case, host the subscriptions on the topic host queue manager.
Topics with few publishers and many subscriptions. In this case, host the publishers on the topic host queue manager.
The following figure shows a topic host queue manager that also hosts the subscriptions. This approach removes the extra "hop" between the publisher and the subscriber, and reduces unnecessary sharing of subscription knowledge across all members of the cluster:Figure 1. Hosting subscriptions on a topic host queue manager
The following figure shows a topic host queue manager that also hosts the publishers. This approach removes the extra "hop" between the publisher and the subscriber, and reduces unnecessary sharing of subscription knowledge across all members of the cluster:Figure 2. Hosting publications on a topic host queue manager
