[ 
https://issues.apache.org/jira/browse/CAMEL-12603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16532322#comment-16532322
 ] 

ASF GitHub Bot commented on CAMEL-12603:
----------------------------------------

oscerd 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-402377752
 
 
   I'm preparing to merge this one.

----------------------------------------------------------------
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:
us...@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)

Reply via email to