[CAMEL-4454] Support for Cluster Singleton routes

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.8.0
• Component/s: camel-core
• Estimated Complexity: Advanced
• Assignee: Unassigned
• Reporter: Vinicius Carvalho
• Created: 15/Sep/11 12:35
• Updated: 09/May/17 09:29
• Resolved: 09/May/17 09:29

Description

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.

Issue Links

• is related to: CAMEL-9886 Create an etcd based RoutePolicy
• is related to: CAMEL-4397 add route support for Hazelcast distributed locking/unlocking
• is superceded by: CAMEL-10320 Provide a LeaderPolicy to ease the implementation of master/slave route/context
• relates to: CAMEL-6399 hazelcast - route policy for having one route being master, and others as slaves