This is part of a series of small blog posts which will cover some of the smaller, perhaps less likely to be noticed, features of IBM MQ. Read other posts in this series.
There are a number of attributes that control the way publications are delivered to subscriber queues when delivery fails.
These range from the most stringent:-
- Make sure every publication message is delivered to every subscriber, and inform the publishing app if anything goes awry.
to a best effort:-
- Give the publication message to anyone who is able to accept it, but don't fret if some can't accept it, and don't bother DLQ-ing it - I don't want my DLQ filling up with these unimportant publications!
Different configuration on the topic is required to request these different behaviours.
To ensure that every subscription must get a successful delivery of a publication message (or none do), the topic must be created with the following attributes.
ALTER TOPIC(VIP.TOPIC) PMSGDLV(ALL)
However it is worth noting that delivery to the Dead-letter queue counts as a successful delivery, so if you'd rather start receiving an error at publication time, as soon as delivery to the subscriber queue fails, rather than when delivery to the Dead-letter queue also fails, then the topic must be created with the following attributes.
ALTER TOPIC(VIP.TOPIC) PMSGDLV(ALL) USEDLQ(NO)
If the publications to your topic are advisory, or only needed on a best effort basis; in other words, it doesn't matter if some subscriptions are unable to receive them, then you could create your topic with the following attributes.
ALTER TOPIC(BEST.EFFORT.TOPIC) PMSGDLV(ALLAVAIL) USEDLQ(NO)
On this one it seems more obvious to avoid using the Dead-letter queue because if you're willing to have some subscribers not receive the publications, then why bother with saving any failed deliveries to the Dead-letter queue.
Message delivery attributes
The examples above all use the PMSGDLV attribute which is the attribute that configures how persistent messages should be treated. There is also another attribute that works in just the same way for non-persistent messages. It is called NPMSGDLV and has the same values.
The above examples illustrate two of the values this attribute can have. Ignoring the ASPARENT value which is there simply to inherit the value from a parent topic in the hierarchy, there is one other value that we have not covered yet.
We have seen:-
which indicates that all subscribers must have a successful delivery of the publication message.
which indicates that the publication can be delivered to those subscribers who can accept it, and not worry about any that can't.
is a combination of the two. It acts like PMSGDLV(ALL) for durable subscriptions, and like PMSGDLV(ALLAVAIL) for non-durable subscriptions.
So now you can control the behaviour of publication delivery on your various topics. Remember, if you choose to make use of the Dead-letter queue, make sure you have a Dead-letter handler program running.