No DCPEvents received when multiple EventHandler's listening (kafka connector)

Java SDK
1

Hi,

We have implemented a solution using the kafka-connector to stream DCPEvents onto kafka and would like to run concurrent connectors for high availability reasons.

The behaviour I am seeing is that a single connector running on it’s own receives all changes as DCPEvents as i expect, but more than one running in parallel results in none of the connectors receive events at all, as if they simply aren’t even being fired. A running connector that is happily receiving all changes as DCPEvents, will seemingly cease to function as soon as another one is fired up, and will continue to not function even when all others have stopped.

Is there are reasonable explanation for this? I would have expected at least one, if not all of the connectors to receive events from the stream, but as i say I cannot see any events even being fired.

Any help would be much appreciated.

I am using kafka-connector 2.0.0, with core-io 1.2.6 and Couchbase version 4.1.0-5005 Enterprise Edition (build-5005).

Cheers,
Tom

2

You have to initialize connectors with different environments and set different dcpConnectionName()

http://docs.couchbase.com/sdk-api/couchbase-core-io-1.2.7/com/couchbase/client/core/env/DefaultCoreEnvironment.Builder.html#dcpConnectionName-java.lang.String-

3

Hi @avsej,

Thanks for that. I have renamed the two differently and that has “worked” - The two connectors now both receive events. They do appear to also share the same state storage in zookeeper, I’m not sure if this was intended or if there is a way around this (As it happens, in my use case this is probably a good thing).

However, running multiple in parallel in this way means we will receive the same event N times, where N is the number of connectors running. Have you had any thoughts on how you would make the connector highly available? Ideally, multiple “identical” connectors would run as a pool where an event is delivered to only one of the pool, or there would be some form of leader election system meaning only one running connector is “active” at any one given moment.

Cheers,
Tom

4

Hey @tkeble,
Not that this helps the other users on the forum, but it just so happens that we’re scheduled to have a call with you on Thursday this week. Both Sergey and I are planning to be there. We haven’t committed the next release yet so we’re looking for input like this. I would encourage others with similar requirements to ping me.
Best,
-Will