MQ

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.

Queue managers have dead-letter queues. That's not news - they've had them for years. You nominate the queue you wish to use as the dead-letter queue by putting its name in the ALTER QMGR DEADQ(name) command. Has your queue manager got one? Have you been forced to remove your dead-letter queue?

The queue manager will use the dead-letter queue in a number of operations; the command server will use it in failure situations; sender channels will use it when they can't send a message that is too big for the channel; receiving channels will use it when they can't deliver a message to a target queue; and publish/subscribe will use it when a published message can't be delivered to a subscriber queue. There are undoubtedly other parts of the queue manager that use it, but those are perhaps the major ones.

The benefit of having a dead-letter queue for channels is that one 'bad' message doesn't cause the channel to stop delivering other messages. You see, without a dead-letter queue, if a channel finds a message it cannot deliver, say because the target queue is full, or because the authority it is using to put the message doesn't have access to the queue, and that message is persistent, it cannot throw the message away, and with no dead-letter queue to use, there is nothing else it can do but rollback the message back onto the transmission queue and stop the channel. With a dead-letter queue in place, the 'bad' message can be put onto that queue out of the way, and the delivery of other messages on the transmission queue can continue.

The benefit of having a dead-letter queue for publish/subscribe is that one unavailable subscriber queue, say because it is full since the durable subscriber application isn't currently reading the messages from the queue, doesn't cause the publish to fail. If the publish fails, none of the other subscribers get the message delivered either and the application has to handle a bad return code.

The trouble with the dead-letter queue is that some applications don't like it, they can't tolerate the out-of-ordering that can happen to their stream of messages when some of them take a trip via the dead-letter queue.

It used to be the case that one application making a statement that it couldn't tolerate a dead-letter queue would mean that every application using that queue manager would have to also forego the benefits of having a system with a dead-letter queue. Not any more. With WebSphere MQ V7.1 and later there is a setting that allows specific channels and topics to opt out of using the dead-letter queue without impacting other channels and other topics. This means that the aforementioned decision on the part of one application does not dictate what other applications have to use.

To do this, you set up the queue manager wide dead-letter queue as before, by issuing a command such as:-

ALTER QMGR DEADQ(QM1.DEAD.LETTER.QUEUE)

and by default all channels and topics will be opted-in to use any dead-letter queue that is specified. The switch that allows you to control specific channels and topics is the USEDLQ attribute, which has values YES and NO (plus ASPARENT on topics for all the normal topic inheritance reasons).

On a specific channel you can opt-out of using the dead-letter queue by issuing a command such as:-

ALTER CHANNEL(TO.QM1) CHLTYPE(RCVR) USEDLQ(NO)

To opt-out on a topic so that publishes won't use the dead-letter queue, you issue a command such as:-

ALTER TOPIC(SALES.RESULTS) USEDLQ(NO)

Of course, I hope you already use a dead-letter queue for all your channels and topics, but if you are in the situation that one application forced your hand and means that your queue manager is running without a dead-letter queue, you now have a way for that application to co-exist with others that would like the benefits of the dead-letter queue in place.