You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2009/06/07 13:23:50 UTC

[jira] Resolved: (CAMEL-1650) Race condition in IdempotentConsumer

     [ https://issues.apache.org/activemq/browse/CAMEL-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-1650.
--------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 2.1.0)
                   2.0.0

trunk: 782371.

Oliver we now eagerly adds to repository to be able to detect duplications of in progress exchanges.

Camel also provides a jpa based repository you can use. Check out camel-jpa and some of the unit tests there.



> 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
>            Assignee: Claus Ibsen
>             Fix For: 2.0.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.