ibmmqmet
commented
2 years ago 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
I already reported this to Spring: https://github.com/spring-projects/spring-framework/issues/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