Unacknowledged messages

[scott9999]

If UNORDERED_ACKNOWLEDGE is used for the session acknowledge mode, and I wish to retry messages 'x' times with multiple subscribers (using Spring JMS) what happens to the unacknowledged messages? As far as I can tell the unAckMessages in the UnorderedAcknowledger just keeps on growing.

If I use CLIENT_ACKNOWLEDGE and don't ack the message as I wish to retry is there anyway to remove it from the list of unacknowledged messages, so it is not implicitly acknowledged (deleted) when a good message is processed and ack'd?

[kuba-aws]

In both cases in JMS you have to call session.recover() to nack messages.

Due do this behavior, the easiest way to work with messages that can fail is to use AUTO_ACKNOWLEDGE mode and set a MessageListener on consumer. If your code throws an exception from the onMessage method, this will nack the message back to the queue.

[scott9999]

thanks for the quick response. That doesn't appear to work, a message that should be retried is deleted immediately.

[kuba-aws]

Ah, sorry, I've missed the part where you've mentioned it's Spring JMS. I've looked through the Spring JMS source code and I have some insight as to what to expect.

If you use AUTO acknowledge mode, Spring JMS will call consumer.receive(), which means message is immediately acknowledged before handing off to Spring JMS (any exceptions processing the message or a sudden death of the JVM process lead to message loss).

If you use CLIENT acknowledge mode, Spring JMS will call consumer.receive() and hand off the message to your callback. If your callback succeeds, Spring JMS will call message.acknowledge(). If your callback fails, Spring JMS will call session.recover(), which is exactly what you want.

Also remember that:

• the scope of session.recover() is limited to only that particular JMS session
• if you use multiple concurrent workers in Spring JMS (concurrentConsumers > 1), each worker owns it's own JMS session, so failing a single message in a worker will call session.recover() just for that message.

So to summarize: if using Spring JMS with Amazon SQS Java Messaging Library, use CLIENT acknowledge mode for best results and throw exceptions from your listener code if you fail to process a message and want it to be retried again (by possibly a different listener).

[reecefenwick]

Sorry to bring this up on a closed issue, but has anyone figured out the best approach for this?

I'm surprised the suggestion for spring-jms is to use CLIENT ack mode when RangedAcknowledger even says in the java doc its not safe for concurrent use

We are experiencing a significant amount of duplicates when using CLIENT ack mode.

Any suggestions welcome, even if that means not using spring-jms

[sanjesh]

The problem with CLIENT_ACKNOWLEDGE is that message is retried immediately on failure of consumption.
Ideally if a message had delaySec configured, they should be retried after delaySec interval. But from the above comments I understand that this isn't supported.

What is the best way to handle message consumption failures while using AWS, SQS, JMS and Spring ?

Our current solution is as below:

1. use CLIENT_ACKNOWLEDGE mode.
2. Catch all exceptions while consuming message. On failure repost the message to the queue with some delaySec.
3. While consuming check publishedTimestamp field in the message body and ignore the message if it is older than certain time period eg: 2 hours.

is there any other better solution ?

[patrick-webs]

@sanjesh to fix the described problem with CLIENT_ACKNOWLEDGE, we forked the repository and are going to use our forked version instead. See #72

this will lead to messages being retried after the expiration of the visibility timeout (30 seconds) rather than immediately.