[
https://issues.apache.org/jira/browse/CAMEL-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482358#comment-17482358
]
Benjamin BONNET commented on CAMEL-6097:
----------------------------------------
Hi,
we have still a race condition between recover and aggregate threads on camel
3.x.
In AggregateProcessor, recover task :
# takes a picture of in progress completed exchanges
# scans completed repo
# recovers any completed exchange from 2 that is not in picture from 1 ant
that is not in progress
So, if a exchange becomes completed after 1 and is dealt by aggregate thread
between 2 and 3 , then it will be considered as completed and not in progress,
and recovery task will recover it.
> Race condition in AggregatorProcessor recovery sometimes causes duplicates
> --------------------------------------------------------------------------
>
> Key: CAMEL-6097
> URL: https://issues.apache.org/jira/browse/CAMEL-6097
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.9.2
> Reporter: Benjamin Truitt
> Assignee: Claus Ibsen
> Priority: Major
> Fix For: 2.9.6, 2.10.5, 2.11.0
>
>
> There seems to be a race condition in
> org.apache.camel.processor.aggregate.AggregateProcessor's RecoverTask. That
> task calls recoverable.scan() to find Exchanges that may need to be
> recovered. Since scan() might return Exchanges that are actually just in
> progress, the RecoverTask then checks to see if the Exchange really is in
> progress. It does this by calling
> inProgressCompleteExchanges.contains(exchangeId). However, that collection
> may have been modified during the time between when scan() returned and when
> contains() is called. This would happen if the in-progress Exchange
> completes before contains() is called. In that situation, inProgress would
> evaluate to false, so the Exchange would be recovered. This results in a
> duplicate Exchange being output by the Aggregator component.
> One possible solution might be to prevent updating the
> inProgressCompleteExchanges during the critical section. Another possible
> solution might be to copy inProgressCompleteExchanges before calling scan().
> I'm sure that there are other ways to deal with this also.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
