https://issues.apache.org/jira/browse/KAFKA-3829
Thanks again Gwen.
More likely that we didn't think of documenting it :)
Do you want to open a JIRA? or submit a doc patch?
We should obviously document this limitation, but I'm thinking that
the REST API could also validate that connector ID doesn't collide
with the distributed worker group.
On Mon, Jun 13, 2016
Thanks Gwen, that was exactly my problem. I had changed the value of the
group.id to the same value as the config name. But rereading the docs I did
not find any hint of that this would occur. Did I miss it somewhere?
-barry
Actually, this is exactly what Connect is doing.
KafkaConnect uses its own "consumer" protocol called "connect" to
distribute tasks between the workers. The default group name for this
is connect-cluster, but it is possible to override it in the
connect-distributed.properties file.
SinkTasks
Thanks Dana,
But this error is for a *single* process using the kafka-connect library.
It does not seem to make any sense that the kafka-connect library would
connect to the broker with two different protocols in the same process. Am
I misunderstanding something?
On Fri, Jun 10, 2016 at 6:55 PM,
> Date: Fri, 10 Jun 2016 16:54:47 +0530
> Subject: Re: error: ... protocols are incompatible with those of existing
> members ??
> From: bkap...@memelet.com
> To: users@kafka.apache.org
>
> I delete the group using kafka-consumer-groups.sh --delete and still I get
> the error.
Barry - i believe the error refers to the consumer group "protocol" that is
used to decide which partitions get assigned to which consumers. The way it
works is that each consumer says it wants to join X group and it can
support protocols (1, 2, 3...). The broker looks at all consumers in group
X
I delete the group using kafka-consumer-groups.sh --delete and still I get
the error.
I didn't really expect this to help, but still, I tried deleting /all/
topics and recreating them. But still my connect app will no longer run due
to this error.
Does this error even have anything to do with persisted state, or is the
broker complaining about live client connections?
