The service uses Spring integration along with Qpid JMS AMQP 1.0 support, to fetch messages from an AMQP queue. For some errors, the error should be retried, and are thus rethrown back to the message-driven-channel-adapter (all channels are direct). The acknowledgement is set to client, and no transaction is used (it is not supported by Microsoft).
Previously, when an error occured and were thrown back to the message-driven-channel-adapter, it would get locked by the broker for a pre-determined time (1min) and the deliveryCount would increase by 1. This made the service behave that each try was with 1min delay, and that you had a maximum of 10 retries.
When upgrading from version 4.0.3 to 4.0.4 or anything later, this has changed. Now, there is timeout value (1min) and I get the same message a couple of ms later. I also see that redeliveryCount is not updated for each retry - when using a third party tool to inspect the queues. And even if the message is moved to a dead-letter-queue when the service tries to do retry, is continues. Thus, it feels like the message some how have been cached.
Looking at the code change from 4.0.3 to 4.0.4 didn't show me many changes, except that Spring Retry also got updated from 1.1.0 to 1.1.1. But as there is no way for me to create a ticket for Spring retry, I've created it here.
So, to sum it all up. Here is logstatemens indicating the difference between the two versions: