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 also have a consumer (to get data from Kafka...), which uses the normal consumer protocol. The name for this group is "connect-" followed by the connector name. The connector name is configured with the connector itself (configuration file or REST). If you somehow managed to give both groups the same name, or (less expected) your connector has yet another consumer group in the plugin itself with the same name, you will see the error you reported. On Sat, Jun 11, 2016 at 10:16 AM, Barry Kaplan <bkap...@memelet.com> wrote: > 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, Dana Powers <dana.pow...@gmail.com> wrote: > >> 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 and picks a protocol that all can support. If there is no common protocol >> you would see this error. Example protocols are 'roundrobin' and 'range' . >> >> You should check the configuration of the group protocol for each consumer >> and also check that you don't have extra consumers in the group, perhaps >> because the group id is reused / common. >> >> Hope this helps, >> >> -Dana >> On Jun 10, 2016 4:24 AM, "Barry Kaplan" <bkap...@memelet.com> wrote: >> >> I delete the group using kafka-consumer-groups.sh --delete and still I get >> the error. >>