[
https://issues.apache.org/jira/browse/CAMEL-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Horne updated CAMEL-12603:
-------------------------------
Description:
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 looks like the following part of the RedeliveryErrorHandler::call should
pick up the fact that the exchange has been interrupted:
{code:java}
// only process if the exchange hasn't failed
// and it has not been handled by the error processor
if (isDone(exchange)) {
callback.done(false);
return;
}{code}
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.
was:
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.
The mapping does get removed from the in-flight messages but the message
continues to get processed in the background.
The RejectedExecutionException set by the interrupt is also overwritten by the
exception thrown by our failing bean.
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.
> Thread stuck in re-delivery loop after interrupting it
> ------------------------------------------------------
>
> Key: CAMEL-12603
> URL: https://issues.apache.org/jira/browse/CAMEL-12603
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Reporter: Nick Horne
> Priority: Major
>
> 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 looks like the following part of the RedeliveryErrorHandler::call should
> pick up the fact that the exchange has been interrupted:
> {code:java}
> // only process if the exchange hasn't failed
> // and it has not been handled by the error processor
> if (isDone(exchange)) {
> callback.done(false);
> return;
> }{code}
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
