[
https://issues.apache.org/activemq/browse/CAMEL-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=52102#action_52102
]
Claus Ibsen commented on CAMEL-1650:
------------------------------------
I added the *remove* operation to the idempotent interface so you can implement
your DB based solution.
And changed the behavior to add the key before processing. And in case of a
failure it will invoke the remove operation so you can process the failed
message at a later stage.
{code}
public interface IdempotentRepository<E> {
/**
* Adds the key to the repository.
*
* @param key the key of the message for duplicate test
* @return <tt>true</tt> if this repository did <b>not</b> already contain
the specified element
*/
boolean add(E key);
/**
* Returns <tt>true</tt> if this repository contains the specified element.
*
* @param key the key of the message
* @return <tt>true</tt> if this repository contains the specified element
*/
boolean contains(E key);
/**
* Removes the key from the repository.
*
* @param key the key of the message for duplicate test
* @return <tt>true</tt> if the key was removed
*/
boolean remove(E key);
}
{code}
> 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.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.
