🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Spring JMSListener fails all the messages in the queue
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?
Answers
-
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
0
