Spring JMSListener fails all the messages in the queue

fkohantorabi

I have a queue endpoint that's configured with

• non-exclusive access
• redelivery enabled with the default redelivery delays
• delivery count of 10
• a dmq queue name
• non partitioned

and pretty much everything else is the default values. I also have a springboot message listeners that

• has a concurrency of 1
• is auto acknowledge
• session is transacted

I have noticed that if I put two message in the queue endpoint in a way that the first message fails processing, the listener will pick up the first message and fail on processing as expected. It will send the message back to the queue and redelivery count on the first message is increased.

What I expect at this point is for the message listener to pick the second message in the queue and process it. However, that does not happen. The second message is never processed by the message listener and the redelivery count on the message is increased.

Now if I change my code so that it doesn't fail on the first message, both message are processed successfully in succession and as expected.

I am assuming what I am experiencing is not right. I would expect the messages to be able to be processed independent of each other and I am assuming this is either due to a configuration error on the queue side or on the consumer side (spring) but I am not sure where to start to look. Does anyone else have the same experience?

Tamimi

Hey @fkohantorabi - curious to know what is your use case for rolling back the transaction until redelivery count is reached?

During transacted sessions, a rollback results in every message in the transaction being redelivered. Any window of messages following the transaction will also get caught in the same delivery count limit, and hence, end up in the DMQ without being received by the application. Note that queue exclusivity may not have an effect on this behaviour.

Some options you can consider:

• Include settlement status in rollback so messages go directly to dmq
• Avoid incrementing delivery count on messages not in rollback

Again, we would ideally like to know what your use-case is and we can have further discussions on this