Input queue of Message in WebSphere MQ Backout Queue

2
votes

In a WebSphere MQ setup, I have several tens of Queues. To avoid poison messages, I am setting up a backout queue. Once the issue that caused the backout is resolved (when this is the case), I want to be able to put the message back on the original input queue. Is there any meta data that can help me understand the origin of the message or do I have to create a backout queue for each queue for that?

The "backout queue for every queue" is to simplify the question and not a real use case.
I see it didn't work and I apologies.
My understanding of your answer here is that in the case I have multiple queues that require backout queue (from business point of view). I can take two paths:

  1. Implemenet a logic that will ,based on content, be able to presume original queue.
  2. Use BO queue per Queue.

Is that correct?

1
ibm-mq

1 Answers

1
votes

If a message lands on the DLQ there is a Dead Letter Header prepended to it. The DLH contains a backout reason and the original queue. However messages that are backed out to user-defined queues have no such header. The idea is that they should be able to be requeued in their original format without requiring any transformation.

However, between using one common backout queue and creating a backout queue for every application queue lies a middle ground. For starters, reply queues generally do not need backout queues. Service endpoint queues and queues for point-to-point interfaces generally do need a backout queue but these are usually made on a per-application basis rather than per-queue. For example, an application that provides service on 5 different endpoint queues may have a common backout queue for those 5 service endpoint queues. It is then possible to look at the content of the messages to tell which of the 5 endpoint queues it came from.

This approach also addresses the problem of having messages from many different applications ending up in the DLQ or the same backout queue. In that case there is an issue of which data owners should be allowed to requeue messages since one might accidentally (or intentionally!) affect another data owner's messages.

So you don't have to provide a backout queue for every input queue but rather provide them for related groups of queues that share the same data owner and where it is possible from context to know from where the message was backed out.

UPDATE
In response to your revision, yes. Where multiple queues share a single backout queue, something must be able to analyze the message content in order to requeue to the original destination. If that is not possible or practical, then a 1:1 relationship between a backout queue and the original queue is necessary.