Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <1022381748.1244231090641.JavaMail.jira@brutus>
Date: Fri, 5 Jun 2009 12:44:50 -0700 (PDT)
From: "Oliver Hecker (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Commented: (CAMEL-1650) Race condition in IdempotentConsumer
In-Reply-To: <1133870737.1243427990802.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


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