[
https://issues.apache.org/jira/browse/CAMEL-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580446#comment-14580446
]
Gareth Western edited comment on CAMEL-7810 at 6/10/15 12:36 PM:
-----------------------------------------------------------------
Does anyone have a unit test that can reproduce this issue? We are experiencing
a similar problem (silently dropped exchanges in a JdbcAggregationRepository),
but we have not yet been able to reproduce it outside of production.
[~bendherville] did you ever submit your pull request?
was (Author: westerg):
Does anyone have a unit test that can reproduce this issue? We are experiencing
a similar problem (silently dropped exchanges in a JdbcAggregationRepository),
but we have not yet been able to reproduce it outside of production.
> Dropped exchanges when aggregating with JdbcAggregationRepository
> -----------------------------------------------------------------
>
> Key: CAMEL-7810
> URL: https://issues.apache.org/jira/browse/CAMEL-7810
> Project: Camel
> Issue Type: Improvement
> Components: camel-sql
> Affects Versions: 2.13.2
> Reporter: K Smith
>
> Part 2 of CAMEL-6144
> bq. A similar Race condition happens when more than one Camel Aggregator(s)
> tries to update a row in the AGGREGATION table. This problem does not lead
> into any exceptions. But it leads into missing exchanges. Because both the
> Aggregator's are trying to update the same row in the AGGREGATION table, But
> one update is overwritten by other update, thus losing an exchange.
> Simple example:
> * I'm awaiting completion based on counting 5 messages.
> * The current data in the aggregation table indicates 3 have been aggregated
> so far.
> * If I have either two threads or two process with a camel route that listens
> to a queue and then aggregates:
> ** thread one gets the existing message from the aggregation table (#3)
> ** thread two gets the existing message from the aggregation table (#3)
> ** thread one aggregates and adds its message to the aggregation table (#4)
> ** thread two does the same then I've lost the message from thread one
> But there is no exception in this case – the optimistic lock is only on the
> message key, there's no versioning going on.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
