You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2018/07/03 12:08:00 UTC
[jira] [Commented] (CAMEL-12603) Thread stuck in re-delivery loop
after interrupting it
[ https://issues.apache.org/jira/browse/CAMEL-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16531262#comment-16531262 ]
ASF GitHub Bot commented on CAMEL-12603:
----------------------------------------
davsclaus commented on issue #2396: CAMEL-12603 - Interrupt fix for messages stuck in a re-delivery loop
URL: https://github.com/apache/camel/pull/2396#issuecomment-402132134
Lets wait to merge this until we get the 2.22.x branch
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
> 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
> Fix For: 2.21.2, 2.22.1, 2.23.0
>
>
> 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)