IBM MQ Backout queue configuration and its implementation

IBM Back out queue

Here we will see What is poision message in mq and how we will handle these messages ,difference between dead queue and a backout queue ..etc .

What is a Poision message in WebSphere MQ and how it will be handled ?

A poison message is a message that cannot be processed by a receiving application. The message could have an unexpected type, or contain information that cannot be handled by the application’s logic. If a poison message is delivered to an application, the application will be unable to process it and will roll it back to the queue where it came from. By default, the IBM MQ classes for JMS will repeatedly redeliver the message to the application. This can result in the application getting stuck in a loop continually trying to process the poison message and rolling it back.

To prevent this from happening, the IBM MQ classes for JMS can detect poison messages, and move them to an alternative destination. To do this, the IBM MQ classes for JMS make use of the following properties:
The value of the BackoutCount field within the MQMD of the message that has been detected.
The IBM MQ queue attributes BOTHRESH (backout threshold) and BOQNAME (backout requeue queue) for the input queue containing the message.
Whenever a message is rolled back by an application, the queue manager automatically increments the value of the BackoutCount field for the message.

When the IBM MQ classes for JMS detect a message that has a BackoutCount greater than zero, they compare the value of the BackoutCount to the value of the BOTHRESH attribute.
If the BackoutCount is less than the value of the BOTHRESH attribute, the IBM MQ classes for JMS deliver it to the application for processing.
However, if the BackoutCount is greater than or equal to BOTHRESH, then the message is considered to be a poison message. In this situation, the IBM MQ classes for JMS then move the message to the queue specified by the BOQNAME attribute. If the message cannot be put to the backout queue, then it is either moved to the queue manager’s dead letter queue or discarded, depending upon the report options of the message.

Defining Backout queue

In MQ if there is any message content error or if receiving application can not process the message correctly from the original queue , then the message is delivered to Backout Queue(TESTQ.BO) instead of original queue.

Here Backout and original queues both are Qmanager objects which are defined in MQ server.
And logic maintained at original queue by defining some queue properties(BOTHRESH and BOQNAME)

[mqm@ip-172-31-14-154 ~]$ runmqsc QM1
5724-H72 (C) Copyright IBM Corp. 1994, 2020.
Starting MQSC for queue manager QM1.


define ql(TESTQ.BO)
     1 : define ql(TESTQ.BO)
AMQ8006I: IBM MQ queue created.

define ql(TESTQ) BOQNAME(TESTQ.BO) BOTHRESH(3)
     5 : define ql(TESTQ) BOQNAME(TESTQ.BO) BOTHRESH(3)
AMQ8006I: IBM MQ queue created.
end
     6 : end
5 MQSC commands read.
3 commands have a syntax error.
All valid MQSC commands were processed.
[mqm@ip-172-31-14-154 ~]$ 

After 3 tries if application fails to process the message fromoriginal queue then it will go to BOQ which is defined in BOQNAME parameter.
and the Queue which is defined in BOQNAME parameter also needed to define similar like original Queue with out BOTHRESH and BOQNAME properties

BOQ mechanism is optional if no TESTQ.BO mechanism is not there the message will go to Dead Queue in case of any processing error.

How to configure a Dead Letter Queue in a Queue Manager ?

2 Ways to configure a Dead letter queue for any Queue Manger

1) Using crtmqm with a ‘-u ‘ switch

2) Use the alter qmgr deadq(‘dead letter queue name’) command from runmqsc

[mqm@ip-172-31-14-154 ~]$ runmqsc QM1
5724-H72 (C) Copyright IBM Corp. 1994, 2020.
Starting MQSC for queue manager QM1.


DISPLAY QMGR DEADQ
1 : DISPLAY QMGR DEADQ
AMQ8408I: Display Queue Manager details.
QMNAME(QM1) DEADQ( )

:
define ql(QM1.DEADQ)
2 : define ql(QM1.DEADQ)
AMQ8006I: IBM MQ queue created.

:
ALTER QMGR DEADQ(QM1.DEADQ)
3 : ALTER QMGR DEADQ(QM1.DEADQ)
AMQ8005I: IBM MQ queue manager changed.

:
DISPLAY qmgr DEADQ
4 : DISPLAY qmgr DEADQ
AMQ8408I: Display Queue Manager details.
QMNAME(QM1) DEADQ(QM1.DEADQ)
end
5 : end
4 MQSC commands read.
No commands have a syntax error.
All valid MQSC commands were processed.
[mqm@ip-172-31-14-154 ~]$

There can be 0 or 1 DLQ for the entire queue manager.You cannot specify multiple DLQs.

What are the differences between the MQ Dead Letter Queue (DLQ or DEADQ) and a Backout queue (BOQNAME)?

The concepts behind the two queues is different. The dead letter queue is what the queue manager uses any time that it runs into problems with the delivery of a message. Rather than throw it away, it will end up on the dead letter queue with a reason.

The backout queue is intended for use by applications in the processing of poison messages. If a bad message gets stuck on an application’s queue, you can specify a backout queue for the application queue and have the application move it.

These are the main differences regarding the Backout queue:

  • The MQ Putting application is NOT the one that moves the message into the DLQ.
  • The queue manager is the one that is in charge of placing the undeliverable message into the DLQ.
  • When doing so, the queue manager will add a “header” to the message, called the Dead Letter Header, with the reason why the message was placed in the DLQ. You will need to use the Dead Letter Handler to properly handle the header and process the message.
  • The BackoutCount attribute in the Message Descriptor is NOT incremented.

b) The Backout Queue is used when dealing with MQ JMS applications and there are defined at the level of each queue (not at the queue manager).
That is, there could be 0, 1, or many more backout queues.
For each “source” queue that is read by the MQ JMS Application, you can define a backout queue (BOQNAME or backout requeue queue).
.
The following example has 3 source queues and 2 backout queues:
if the source queue is Q1 then you could have BOQNAME(BOQ1) and poison messages can be moved by the MQ JMS libraries from Q1 to BOQ1.
If the source queue is Q2 then you could have BOQNAME(BOQ2) and poison messages can be moved by the MQ JMS libraries from Q2 to BOQ2.
If the source queue is Q3 then you could have BOQNAME(BOQ2) to reuse an existing backout queue and poison messages can be moved by the MQ JMS libraries from Q3 to BOQ2.

These are the main differences regarding the DLQ:

  • The MQ classes for JMS are the ones that move the message into the backout queue.
  • Or the MQ Putting Application can have extra logic to move the message into the backout queue.
  • The queue manager does NOT move messages into the Backout queue
  • The message that is placed in a backout queue does NOT have an extra header.
  • If the MQ classes for JMS are the ones that handle the message, then the BackoutCount attribute in the Message Descriptor is incremented.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *