[jira] [Commented] (CAMEL-7810) Dropped exchanges when aggregating with JdbcAggregationRepository

["K Smith (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-7810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14132007#comment-14132007 ] 

K Smith commented on CAMEL-7810:
--------------------------------

I did find someone's implementation of an AggregationRepository that factors versioning in:
http://grepcode.com/file/repo1.maven.org/maven2/org.nhind/direct-msg-monitor/1.1/org/nhindirect/monitor/aggregator/repository/ConcurrentJPAAggregationRepository.java

bq. This specific implementation throws a Runtime exception on DAO errors. This implementation also checks for consistency/concurrency of the exchange. If the attempted exchange does match the latest and greatest exchange version, then an AggregationVersionException is wrapped by the runtime error. Routes using this repository should catch the AggregationVersionException and attempt to retry the exchange. If exception handling and redelivery is configured correctly, Camel should automatically reload the exchange from the latest version in the and attempt the aggregation process again.

This prevents dropping/losing messages like the current camel implementation JdbcAggregationRepository can when in a multithreaded or cluster environment.



> Dropped exchanges when aggregating with JdbcAggregationRepository
> -----------------------------------------------------------------
>
>                 Key: CAMEL-7810
>                 URL: https://issues.apache.org/jira/browse/CAMEL-7810
>             Project: Camel
>          Issue Type: Bug
>          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)