The theory is that when publishing in a cluster topic, a copy of the message is delivered to all queue managers subscribed to that topic via a subscription object.
The question is a pure theoretical one: is the copy of the message delivered to the target queue manager via cluster channels? Are the cluster channels used for this purpose?
If the answer is no, then which is the mechanism that delivers a copy of the publication from origin to destination?
The short answer is yes IBM MQ uses cluster channels to deliver messages published to clustered topics if the publisher is not local to the queue manager where a subscription is made.
The longer answer is that for IBM MQ v7.0/7.1/7.5 the delivery was always directly from the queue manager were the publish happened to all the queue managers that registered proxy subscriptions to that topic.
The issue with this is that every queue manager in the cluster needs to know about every other queue manager in the cluster AND every subscriber to any clustered topic in the cluster. In a large cluster even if only two queue managers are participating in the clustered pub/sub every queue manager in the cluster needs to know about every other queue manager and the subscriptions.
When you first cluster a topic on a PR (partial repository) queue manager it would notify the FRs (full repositories) about the new topic and they would then send this out to every PR queue manager in the cluster along with information about how to connect to every other PR in the cluster. If you had a thousand PR queue managers in the cluster that means each PRs will now have knowledge of the 999 other PRs.
In addition when you add a subscription to a clustered topic on any PR, that PR will connect out to every other PR and tell it to setup a proxy subscription, that means that PR will start 999 CLUSSDR channels to propagate this proxy subscription.
After this initial propagation of information, if only two PRs were using pub/sub, for example publisher app publishes to the topic on PR1 and subscriber app subscribes to the topic on PR2, other than cluster updates about the topic there would be communication only between PR1 and PR2.
This is different than clustered QUEUE behavior. When you first cluster a QUEUE the PR queue manager it will notify the FRs (full repositories) about the QUEUE. At this point the FRs do not need to notify other PRs (they do how ever notify the other FRs). If you then want to put to that clustered queue on another PR, if the PR does not know about the queue it will go to the FR to see if the queue exists and if it does the FR sends information about it to the PR. The FR then knows that the PR has interest in that object and any further updates to the clustered QUEUE are only sent to the interested PRs. PRs also periodically will let the FR know they are still interested if applications continue to put to the clustered queue to keep this interest alive, but if applications stop using the queue eventually the PR will not express interest and the FR will stop sending updates to that PR.
In MQ v8 IBM added routed pub/sub for clusters and the original is now called direct pub/sub.
You can now change the behavior of a clustered topic with the new attribute CLROUTE, this can be set to DIRECT which is the default and works as things did before MQ v8, or you can get the new behavior by setting it to TOPICHOST.
The first part of what I said remains the same in that every PR in the cluster will get a update from the FR about the new clustered TOPIC, but they will only learn about the one PR that you defined the TOPIC on not all other queue managers in the cluster.
When a subscription is made to a TOPIC, the PR where the subscription is made will only connect to the PR that has the clustered TOPIC defined with CLROUTE(TOPICHOST), not to all other PRs to create the proxy subscription. If a message is published to the topic on any PR, that PR will send it to only to the TOPICHOST which will then send it to the other PRs that notified it of the proxy subscription. (Note you can and should have more than one TOPICHOST for redundancy, but I didn't get into those details).
Angel Rivera from IBM MQ L2 support presented a Webcast on this topic that is very good, you can access the PDF and MP3 of the audio here: MQ Pub/Sub: Topic host routing clusters.
