unexpected backout behaviour with DMLC and Websphere MQ

[apinske]

I already reported this to Spring: spring-projects/spring-framework#27987
But might be interesting to document here as well.

Websphere MQ has a strange way of backout handling (i.e. moving poison messages). It does not move poison messages to the backout queue immediately on the "final" rollback, but only increments the internal BackoutCount (to be one more than it should be able to be) and leaves the message on the initial queue. The actual move is performed in a subsequent (unrelated!) receive-call. This is documented here.

DMLC uses a polling approach and thus is susceptible to the described behaviour. It is not really possible to observe this behaviour, as any attempt to "see" the messages moves it to the right queue. Only way is to "not observe" the message already being in the backout queue.

The practical implications are two-fold:

• A single poison message is not immediately visible on the appropriate backout queue for handling. Is is only moved when a next receive-pass commits (takes in the worst case the amount of receive-timout + handling of an unrelated msg).
• In a scenario where temporarily all/many messages are poison the move-to-backout-operations may also rollback.

• ibmmq-jms-spring 2.6.3
• all Java versions
• A small code sample that demonstrates the issue: https://github.com/apinske/playground-mq/tree/backout-wmq

[ibmmqmet]

I'm not really clear what you think the problem is. But in any case, any application that uses the MQ JMS classes in either a synchronous or asynchronous (usually something like a JEE MDB) fashion will be building on the documented behaviour. If you want to suggest a change to MQ's JMS code, then you can always raise an idea here. But there's nothing that can be done at this layer to change it.

[apinske]

My thoughts were:

• Spring/DMLC with MQ may lead to unexpected behaviour.
• This lib encourages the use of SpringBoot+DMLC with MQ.
• Therefore it should at least document this behaviour for its users. And in the best case provide ways to mitigate the issues.

I don't think most users of this lib (or boot for that matter) even recognise that the docs about "receives messages synchronously" apply to them, i.e. that spring uses a polling approach for message listeners.

I also voted/commented on https://integration-development.ideas.ibm.com/ideas/MESNS-I-190.