[
https://issues.apache.org/jira/browse/CAMEL-4454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luca Burgazzoli closed CAMEL-4454.
----------------------------------
Resolution: Fixed
Fix Version/s: (was: Future)
> Support for Cluster Singleton routes
> ------------------------------------
>
> Key: CAMEL-4454
> URL: https://issues.apache.org/jira/browse/CAMEL-4454
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 2.8.0
> Reporter: Vinicius Carvalho
>
> We came up with this problem in our company. I'll try to give a scenario to
> show the possible need for this feature:
> ================================== The problem =============================
> We have an application bundle in a ear that contains a camel context and some
> routes. Due the need of HA of the application, this EAR is replicated over
> several nodes. By doing this, our camel context also get replicated. For most
> of our usage it's ok to have competing consumers/producers. But we have one
> specific case where this is a problem.
> In one end is our cluster with several instances, and we rely heavily on JMS.
> One specific Queue we use durable subscription to achieve a single consumer
> on the cluster, while at the same time, in case of failure another node start
> consuming messages.
> On the other side, there's an app that uses Hazelcast as a broker for
> messaging. We then created a route to consume some messages from the
> hazelcast cache to our Queue on the cluster.
> Now, if we deploy this route as part of our distribute app, we end with
> several instances and messages gets duplicated at the destination on the
> cluster. We need only one active route on the cluster.
> One could achieve this by deploying the routes to only one app instance, but
> it would lead to problems when that instance crashes. So we fixed this by
> putting the ear on JBoss deployha-singleton, which offers us the ability to
> have only one single active instance at the time. That was ok for us, but we
> are relying on specific appserver infrastructure for that.
> ============================== Proposal ===========================
> If camel somehow used jgroups for instance to comunicate with other
> instances, it could use the mechanism that jgroups has to elect a master-view.
> Every master-view context would then deploy it's singleton routes. All other
> instances would go on passive mode, and have a MessageListener for cluster
> messages. In case a view has changed because a node dies, the context would
> then check if it is the new master view, and in positive deploy the singleton
> routes.
> It could be a nice addition to camel on a cluster. Maybe even add the jgroups
> support for more features on the core when requesting cluster based
> coordination.
> I'm currently trying this not at camel level, but we have CDI extension
> bootstraping camel (not using camel-pe for some other reasons). And our
> extension will then perform this uniqueness in cluster using jgroups to
> manage the master node, and invoking context.addRoutes(). We separate the
> external routes by using CDI qualifiers on the RoutesBuilder.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
