Publish/subscribe hierarchy scenario 3: Using a cluster channel to add a queue manager
This is the third in a set of three scenarios that set up a publish/subscribe hierarchy in different ways to establish the connection between queue managers. This scenario uses a cluster channel to add a queue manager to a hierarchy.
About this task
This set of scenarios all use a parent queue manager called QM1, and two child queue managers called QM2, and QM3.
Note: This scenario is only using the cluster configuration to connect queue managers together, not to propagate publish/subscribe traffic through clustering topics. When defining child/parent hierarchy relationships between queue managers in the same cluster, propagation of publications between queue managers will occur based on the publication and subscription scope settings of the topics in the topic tree. It is important not to use the cluster name setting of a topic to add the topics into the cluster. If using the cluster name, the topology becomes a publish/subscribe cluster and does not require the child/parent hierarchy relationships defined. See Scenario: Creating a publish/subscribe cluster and Planning your distributed publish/subscribe network.
This scenario creates a cluster called
DEMO
where QM1 and QM2 are full repositories, and QM3 is a partial repository. Queue manager QM1 is the parent of queue managers QM2 and QM3.
Procedure
Create the queue managers.
Create and start three queue managers called QM1,
QM2, and QM3 using the following commands: