You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2015/07/12 00:01:04 UTC

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

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

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

This is more hard core to look into. Wonder if some of those memory data-grid are better as repos.

> 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.4#6332)