[
https://issues.apache.org/activemq/browse/CAMEL-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52091#action_52091
]
Oliver Hecker commented on CAMEL-1650:
--------------------------------------
Andi summarized quite exaclty what I am looking for. I think this is how
interaction with the IdempotentRepository should look like to make shure it
works in a parallel processing scenario.
The old implementation (pre CAMEL-1451) had the issue that the message gets
lost when the route fails after checking the repository.
The current implentation has the issue that there might be duplicates because
identical messages are not detected unless the first one gets processed
completely.
The solution with the in memory cache might improve the situation but will have
no effect in my main use case (Quartz trigger duplicates) because here the
duplicate messages occur on always on different machines. So in this scenario a
synchronization via database is required to make it work.
> Race condition in IdempotentConsumer
> ------------------------------------
>
> Key: CAMEL-1650
> URL: https://issues.apache.org/activemq/browse/CAMEL-1650
> Project: Apache Camel
> Issue Type: Bug
> Components: camel-core
> Affects Versions: 2.0-M1
> Reporter: Oliver Hecker
> Fix For: 2.1.0
>
> Attachments: IdempotentConsumerTest.java
>
>
> A possible possible race condition exists in the IdempotentConsumer
> implementation:
> The code first checks in the MessageIdRepository if the message was already
> processed. If not then it processes the message and
> afterwards adds the id to the repository. (See also
> http://issues.apache.org/activemq/browse/CAMEL-1451). There is no locking
> between the check with "contains" and the insert with "add". So if multiple
> threads/instances try this in parallel for the same id, then
> it might happen that more than one finds the id not yet contained in the
> repository and the same message is processed multiple
> times.
> I enclose an extended version of IdempotentConsumerTest which illustrates the
> problem.
> It is important to note that even if the test demonstrates the issue with an
> MemoryIdempotentRepository a solution should also
> address the case of a database based respository in a clustered environment.
> So this might imply that some locking mechanism on the
> database is required.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
