MQ message re-delivery using MQ JMS classes and spring

2
votes

Our application is consuming messages from WebSphere MQ using MQ JMS classes with spring. MQ queue definition has not set any value for backout threshold (BOTHRESH) and backout queue name (BOQNAME). In session transacted mode, when an exception occurs while processing message, no message delivery retry happens. I see exception that says no blackout queue defined. Since its not defined, it was trying to add message to dead letter queue. That's also failed. My questions are -

  1. Is message re-delivery possible with MQ JMS classes when BOTHRESH = 0?
  2. With above setup, is it possible to manage message delivery retry by application code using redelivery count?
2
javaspringjmsibm-mq
Just to be clear, i see this exception in the first attempt itself. I expected that , after exception, message redelivery happens and onMessage() will be called with incremented redelivery count in message property. But i observed that, onMessage is not called at all after exception and i see exceptions mentioned above multiple times since poison message is still in the main request queue – mformusic
A BOTHRESH of 0 will cause the MQ JMS code to never requeue the message to the backout queue. So in your case I'd expect it to be redelivered. It's likely the Spring code is doing something to cause the message not to be redelivered. In a normal J2EE environment using the MQ JCA RA, I would expect message redelivery. – Tim McCormick

2 Answers

0
votes

According to the IBM Knowledge Center page on backout behavior,

If the backout threshold value is zero, poison message handling is disabled, and poison messages remain on the input queue. Otherwise, when the backout count reaches the threshold value, the message is sent to the named backout queue. If the backout count reaches the threshold value, but the message cannot go to the backout queue, the message is sent to the dead-letter queue or it is discarded.

The intent is that you would, in fact, be able to manage redelivery in the app code using the JMSX_DELIVERY_COUNT or JMS_IBM_MQMD_BackoutCount.

I suspect that the Knowledge Center is at least slightly wrong in that it says the message failing requeue will be discarded. I believe that applies only to non-persistent messages and have submitted feedback asking for clarification.

However, my understanding of the backout behavior is that it is described correctly in the Knowledge Center and that the behavior you are seeing is not what is expected from IBM's JMS classes. There are two possibilities. The first is that the unexpected behavior is implemented in the Spring code rather than IBM's JMS code. The second is that MQ JMS has a bug and isn't behaving as per the docs.

Usually I'd apply the "what is more likely?" test and "MQ bug" doesn't rise to the top of that list. However, I don't know Spring, the likelihood of dedicated poison message handling code, or the general quality of Spring code. So I'd recommend either using stand-alone JMS code to perform the same test, or open a PMR and work with IBM Support to trace the code and isolate the classes where the backout fails.

0
votes

I'm using MQ 7.5 with BackOut BOTHRESH(1) and BOQNAME(SAMEQUEUE). In my case I use SOURCE QUEUE as the same in BOQNAME, so my main QUEUE is also my DLQ QUEUE that enable message rotate to my consumer. In Spring configuration I just use sessionTransacted="true". Another thing that I did was when use DLQ in BOQNAME after some time I used "q" utility to move messages from DLQ again to main queue.

Hope that helps.