Resynchronization of proxy subscriptions

Under normal circumstances, queue managers automatically ensure that the proxy subscriptions in the system correctly reflect the subscriptions on each queue manager in the network. Should the need arise, we can manually resynchronize a queue manager's local subscriptions with the proxy subscriptions that it propagated across the network using the REFRESH QMGR TYPE(PROXYSUB) command. However, you should do so only in exceptional circumstances.


When to manually resynchronize proxy subscriptions

When a queue manager is receiving subscriptions that it should not be sent, or not receiving subscriptions that it should receive, you should consider manually resynchronizing the proxy subscriptions. However, resynchronization temporarily creates a sudden additional proxy subscription load on the network, originating from the queue manager where the command is issued. For this reason, do not manually resynchronize unless IBM MQ service, IBM MQ documentation, or error logging instructs you to do so.

You do not need to manually resynchronize proxy subscriptions if automatic revalidation by the queue manager is about to occur. Typically, a queue manager revalidates proxy subscriptions with affected directly-connected queue managers at the following times:

  • When forming a hierarchical connection
  • When modifying the PUBSCOPE or SUBSCOPE or CLUSTER attributes on a topic object
  • When restarting the queue manager
Sometimes a configuration error results in missing or extraneous proxy subscriptions:

  • Missing proxy subscriptions can be caused if the closest matching topic definition is specified with Subscription scope set to Queue Manager or with an empty or incorrect cluster name. Note that Publication scope does not prevent the sending of proxy subscriptions, but does prevent publications from being delivered to them.
  • Extraneous proxy subscriptions can be caused if the closest matching topic definition is specified with Proxy subscription behavior set to Force.
When configuration errors cause these problems, manual resynchronization does not resolve them. In these cases, amend the configuration. The following list describes the exceptional situations in which you should manually resynchronize proxy subscriptions:

  • After issuing a REFRESH CLUSTER command on a queue manager in a publish/subscribe cluster.
  • When messages in the queue manager error log tell you to run the REFRESH QMGR TYPE(REPOS) command.
  • When a queue manager cannot correctly propagate its proxy subscriptions, perhaps because a channel has stopped and all messages cannot be queued for transmission, or because operator error has caused messages to be incorrectly deleted from the SYSTEM.CLUSTER.TRANSMIT.QUEUE queue.
  • When messages are incorrectly deleted from other system queues.
  • When a DELETE SUB command is issued in error on a proxy subscription.
  • As part of disaster recovery.


How to manually resynchronize proxy subscriptions

First rectify the original problem (for example by restarting the channel), then issue the following command on the queue manager: 
 REFRESH QMGR TYPE(PROXYSUB)

When you issue this command, the queue manager sends, to each of its directly-connected queue managers, a list of its own topic strings for which proxy subscriptions should exist. The directly-connected queue managers then update their held proxy subscriptions to match the list. Next, the directly-connected queue managers send back to the originating queue manager a list of their own topic strings for which proxy subscriptions should exist, and the originating queue manager updates its held proxy subscriptions accordingly.

Important usage notes:

  • Publications missed due to proxy subscriptions not being in place are not recovered for the affected subscriptions.
  • Resynchronization requires the queue manager to start channels to other queue managers. If you are using direct routing in a cluster, or you are using topic host routing and this command is issued on a topic host queue manager, the queue manager will start channels to all other queue managers in the cluster, even those that have not performed publish/subscribe work. Therefore the queue manager that you are refreshing must have enough capability to cope with communicating with every other queue manager in the cluster.
  • If this command is issued on z/OS® when the CHINIT is not running, the command is queued up and processed when the CHINIT starts.