[
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 seems 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.
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.
> 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 seems 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)
