Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
2.0-M1
-
None
Description
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.
Attachments
Attachments
Issue Links
- is depended upon by
-
CAMEL-1679 InProgress repository
- Closed
-
CAMEL-1680 Idempotent consumer repository - support reserving locks and timeouts
- Closed