[jira] [Commented] (CAMEL-4271) jdbc aggregation repository - recovery taks and cluster issue

["Claus Ibsen (JIRA)" <ji...@apache.org>]

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

Claus Ibsen commented on CAMEL-4271:
------------------------------------

Either there should be some SQL table locking or maybe use an external clustered data-grid with cluster locks like hazelcast / etcd / zookeeper etc to let the recovery task only run on one active node.

> jdbc aggregation repository - recovery taks and cluster issue
> -------------------------------------------------------------
>
>                 Key: CAMEL-4271
>                 URL: https://issues.apache.org/jira/browse/CAMEL-4271
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core, camel-sql
>    Affects Versions: 2.8.0
>            Reporter: Claus Ibsen
>             Fix For: Future
>
>
> If you enable recovery on the aggregator eip when using a persistent repository such as the jdbc, then you may have a race condition when having multiple camel apps running in a cluster. As the aggregate recover task is running on each Camel app (node) in the cluster. So they may potentially all pickup recovery tasks, and execute those, which may cause duplicate messages being recovered.
> What is needed is a lock table or some other way to ensure only one recover tasks "wins" and executes.
> We may want to enhance the API in camel to facilitate this kind of locking. As with hawtdb you may have a shared file on the SAN and thus have the same racing issue.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)