Cluster topic attributes
When a topic object has the cluster name attribute set, the topic definition is propagated across all queue managers in the cluster. Each queue manager uses the propagated topic attributes to control the behavior of publish/subscribe applications.
A topic object has a number of attributes that apply to publish/subscribe clusters. Some control the general behavior of the publishing and subscribing applications and some control how the topic is used across the cluster.
A clustered topic object definition must be configured in a way that all queue managers in the cluster can correctly use it.
For example if the model queues to be used for managed subscriptions ( MDURMDL and MNDURMDL ) are set to a non-default queue name, that named model queue must be defined on all queue managers where managed subscriptions will be created.
Similarly, if any attribute is set to ASPARENT, the behavior of the topic will be dependent on the higher nodes in the topic tree (see Administrative topic objects ) on each individual queue manager in the cluster. This might result in different behavior when publishing or subscribing from different queue managers.
The main attributes that directly relate to publish/subscribe behavior across the cluster are as follows:
- CLROUTE
- This parameter controls the routing of messages between queue managers where publishers are connected, and queue managers where matching subscriptions exist.
- You configure the route to be either direct between these queue managers, or through a queue manager that hosts a definition of the clustered topic. See Publish/subscribe clusters for more details.
- We cannot change the CLROUTE while the CLUSTER parameter is set. To change the CLROUTE, first set the CLUSTER property to be blank. This stops applications that use the topic from behaving in a clustered manner. This in turn results in a break in publications being delivered to subscriptions, so you should also quiesce publish/subscribe messaging while making the change.
- PROXYSUB
- This parameter controls when proxy subscriptions are made.
Note: Setting the PROXYSUB(FORCE) attribute in a large or busy publish/subscribe cluster can result in excessive load on system resources. The PROXYSUB(FORCE) attribute is propagated to every queue manager, not just the queue manager that the topic was defined on. This causes every queue manager in the cluster to create a wildcarded proxy subscription.
- FIRSTUSE is the default value, and causes proxy subscriptions to be sent in response to local subscriptions on a queue manager in a distributed publish/subscribe topology, and canceled when no longer required. For details about why you might want to change this attribute from the default value of FIRSTUSE, see Individual proxy subscription forwarding and publish everywhere .
- To enable publish everywhere, you set the PROXYSUB parameter to FORCE for a high-level topic object. This results in a single wildcard proxy subscription that matches all topics below this topic object in the topic tree.
A copy of a message to this topic, published on any queue manager in the cluster, is sent to every queue manager in the cluster - either directly, or through a topic host queue manager, depending on the CLROUTE setting.
When the topic is direct routed, every queue manager creates cluster sender channels to every other queue manager. When the topic is topic host routed, channels to each topic host queue manager are created from every queue manager in the cluster.
For more information about the PROXYSUB parameter when used in clusters, see Direct routed publish/subscribe performance.
- PUBSCOBE and SUBSCOPE
- These parameters determine whether this queue manager propagates publications to queue managers in the topology (publish/subscribe cluster or hierarchy) or restricts the scope to just its local queue manager. We can do the equivalent job programmatically using MQPMO_SCOPE_QMGR and MQSO_SCOPE_QMGR.