camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Hecker (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CAMEL-1650) Race condition in IdempotentConsumer
Date Fri, 05 Jun 2009 19:44:50 GMT

    [ 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.


Mime
View raw message