Design considerations for retained publications in publish/subscribe clusters
There are a few restrictions to consider when designing a publish/subscribe cluster to work with retained publications.
Considerations
Consideration 1: The following cluster queue managers always store the latest version of a retained publication:
- The publisher's queue manager
- In a topic host routed cluster, the topic host (provided there is only one topic host for the topic, as explained in the next section of this article)
- All queue managers with subscriptions matching the topic string of the retained publication
Consideration 2: Queue managers do not receive updated retained publications while they have no subscriptions. Therefore any retained publication stored on a queue manager that no longer subscribes to the topic will become stale.
Consideration 3: On creating any subscription, if there is a local copy of a retained publication for the topic string, the local copy is delivered to the subscription. If we are the first subscriber for any given topic string, a matching retained publication is also delivered from one of the following cluster members:
- In a direct routed cluster, the publisher's queue manager
- In a topic host routed cluster, the topic hosts for the given topic
Delivery of a retained publication from a topic host or publishing queue manager to the subscribing queue manager is asynchronous to the MQSUB calls. Therefore, if we use the MQSUBRQ call, the latest retained publication might be missed until a subsequent call to MQSUBRQ.
Implications
For any publish/subscribe cluster, when a first subscription is made, the local queue manager might be storing a stale copy of a retained publication and this is the copy that is delivered to the new subscription. The existence of a subscription on the local queue manager means that this will resolve the next time the retained publication is updated.
For a topic host routed publish/subscribe cluster, if you configure more than one topic host for a given topic, new subscribers might receive the latest retained publication from a topic host, or they might receive a stale retained publication from another topic host (with the latest having been lost). For topic host routing, it is usual to configure multiple topic hosts for a given topic. However, if you expect applications to make use of retained publications, we should configure only one topic host for each topic.
For any given topic string, we should use only a single publisher, and ensure the publisher always uses the same queue manager. If we do not do this, different retained publications might be active at different queue managers for the same topic, leading to unexpected behavior. Because multiple proxy subscriptions are distributed, multiple retained publications might be received.
If we are still concerned about subscribers using stale publications, consider setting a message expiry when you create each retained publication.
We can use the CLEAR TOPICSTR command to remove a retained publication from a publish/subscribe cluster. In certain circumstances you might need to issue the command on multiple members of the publish/subscribe cluster, as described in CLEAR TOPICSTR .
Wildcard subscriptions and retained publications
If we are using wildcard subscriptions, the corresponding proxy subscriptions delivered to other members of the publish/subscribe cluster are wildcarded from the topic separator immediately prior to the first wildcard character. See Wildcards and cluster topics.
Therefore the wildcard used might match more topic strings, and more retained publications, than will match the subscribing application.
This increases the amount of storage needed for the retained publications, and you therefore need to ensure that the hosting queue managers have enough storage capacity.
Parent topic: Designing publish/subscribe clusters
Related information