Redelivery messages to consumers

[alejandro-jara]

Hello, I hope you are well. I am receiving the messages and with the payload making an HTTP request to an api. This api could return a successful status or for some reason a status with 4xx code. In these cases I am only executing acceptAsync only if the status is 2xx for the others I do nothing. In these cases the messages continue to exist in the queue but are not sent again. Should this be contemplated using reject() or should it be a setting of Artemis itself?

Thank you very much and sorry for the inconvenience

[Havret]

Hello @alejandro-jara,

You definitely cannot leave it as it is. If you don't acknowledge a single message nothing terrible will happen immediately. The message will just hang in the "limbo". It won't be redelivered to other consumers until the original consumer that received it lives. In the long run this may block your consumer due to the run out of the consumer credit [1]. It some situations (when the message grouping is enabled), it may even lead to the blockage of the entire queue.

There are few schools of thought how to tackle this kind of situations.

You can reject the message by calling Reject. It will result in a message being immediately redelivered. You can instruct the broker that this particular consumer doesn't want to see the same message again by setting the flag undeliverableHere to true.

The downside of this approach is that it may disrupt the message ordering, as you are effectively putting the message back on the queue. If the future redeliveries end up in rejections as well, you may end up in the loop. The message will be redelievered until you successfully acknowledge it or its TimeToLive expires. In this case the message will be transferred to the ExpiryQueue and sit there until it's consumed.

The other approach that is quite popular if you don't have any infrastructure built around the ExpiryQueue is always acknowledge. If you have an error in your application, for instance you got 4xx http code from the external service you know that there is no point in redelivering this message. 4xx indicates that the error is terminal so additional executions will end up in the same erroneous output. In this case you should log an error (maybe capture the payload of the message for future investigation) and simply acknowledge the message as it is. If, on the other hand you got 5xx error code from the external service, it indicates that the error may be transient (the external service is down for whatever reason), so you should try again later. There is no point in involving the broker in the retry procedure. If you got 5xx for this message there is a high chance that you will get the same error with forthcoming messages. So you should retry on the client. There is quite a few great libraries that can this for you [3].

Sorry for the long answer. I hope all the points are clear.

Best,
Havret

[1] https://havret.github.io/dotnet-activemq-artemis-client/docs/consumer-credit
[2] https://github.com/App-vNext/Polly