[
https://issues.apache.org/jira/browse/CAMEL-8010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129189#comment-16129189
]
ASF GitHub Bot commented on CAMEL-8010:
---------------------------------------
GitHub user rajithapl opened a pull request:
https://github.com/apache/camel/pull/1894
CAMEL-8010:Locking the critical section to avoid race condition if Ag…
…gregateTimeOutChecker also completes at the same time as Recover task
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rajithapl/camel CAMEL-8010_RaceCondition
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/1894.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1894
----
commit 3f13fb36727cf488d3c5afeac1c84ef877514925
Author: Rajithamol <rlakshma...@mediaocean.com>
Date: 2017-08-16T18:10:30Z
CAMEL-8010:Locking the critical section to avoid race condition if
AggregateTimeOutChecker also completes at the same time as Recover task
----
> Race condition in AggregatorProcessor recovery sometimes causes duplicates
> (still)
> ----------------------------------------------------------------------------------
>
> Key: CAMEL-8010
> URL: https://issues.apache.org/jira/browse/CAMEL-8010
> Project: Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.14.0
> Reporter: Marc Carter
>
> CAMEL-6097 Patched a pretty clear race condition between the completion
> thread (CT) and recovery thread (RT) but leaves several holes when exercised
> with a Jdbc repository and a separate aggregation thread (AT).
> #1 is relevant to all repository backends.
> #2 only affects fully transactional backends
> I'm currently taking a look into this bug as its a show-stopper that
> _persistent_ repositories actually *decreases* reliability. (Untested)
> workaround is to add an in-memory idemptotentconsumer immediately after the
> aggregation.
> Here AT starts and completes an aggregation between defensive copy and when
> RT repo scanning starts. CT then confirms it (in memory (*)) before repo
> scanning ends.
> || AT || RT || CT ||
> | | inProg COPY to inProgCopy | |
> | repo START x | | |
> | | | repo REMOVE x |
> | | | <commit> |
> | | | inProg ADD x |
> | | repo SCAN (sees x) | |
> | | | {color:red}process x{color} |
> | | | repo CONFIRM x |
> | | | inProg REMOVE x |
> | | | <commit> |
> | | x not inProg or inProgCopy | |
> | | {color:red}process x{color} | |
> | | repo CONFIRM x | | Fails silently as this is doInTransactionWithoutResult
> | | <commit> | |
> {noformat}SQLWarning ignored: SQL state '02000', error code '10000', message
> [No row was found for FETCH, UPDATE or DELETE; or the result of a query is an
> empty table.]{noformat}
> (*) Side note: inProgressExchanges is updated by a {{Synchronisation}} inside
> the UOW so is immediately visible although any DB change may not be visible
> for ages (in threading terms) as the entire transaction must commit first.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
