I have experienced an issue where we could not cancel a message stuck in a re-delivery cycle. I was using Jolokia and calling the interrupt method on the DefaultAsyncProcessorAwaitManager for the blocked exchange and I had expected the re-delivery cycle to stop.
This does not happen, and the blocked message continues to get executed and re-delivered. The mapping does get removed from the in-flight messages though. I can see also that the RejectedExecutionException set by the interrupt is also overwritten by the exception thrown by our failing bean. I think the problem here is that there are no checks for this RejectedExecutionException during the re-delivery cycle.
It seems like the following part of the RedeliveryErrorHandler::call should pick up the fact that the exchange has been interrupted:
This is an issue if you have configured a long re-delivery cycle and you have a message retrying that you know will never succeed.