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 we should also quiesce publish/subscribe messaging while making the change.

PROXYSUB

This parameter controls when proxy subscriptions are made.

• 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.

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.

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.

PUBSCOPE

If a cluster topic object is defined with PUBSCOPE(QMGR), the definition is shared with the cluster, but the scope of publications that are based on that topic is local only and they are not sent to other queue managers in the cluster.

SUBSCOPE

If a cluster topic object is defined with SUBSCOPE(QMGR), the definition is shared with the cluster, but the scope of subscriptions that are based on that topic is local only, therefore no proxy subscriptions are sent to other queue managers in the cluster.

These two attributes are commonly used together to isolate a queue manager from interacting with other members of the cluster on particular topics. The queue manager neither publishes or receives publications on those topics to and from other members of the cluster. This situation does not prevent publication or subscription if topic objects are defined on subtopics.

Set SUBSCOPE to QMGR on a local definition of a topic does not prevent other queue managers in the cluster from propagating their proxy subscriptions to the queue manager if they are using a clustered version of the topic, with SUBSCOPE(ALL). However, if the local definition also sets PUBSCOPE to QMGR those proxy subscriptions are not sent publications from this queue manager.

Parent topic: Defining cluster topics

Related information

• Publication scope
• Subscription scope