[
https://issues.apache.org/jira/browse/KAFKA-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16854774#comment-16854774
]
Sagar Rao commented on KAFKA-7995:
----------------------------------
[~bchen225242] I see that there's an error called *INCONSISTENT_GROUP_PROTOCOL*
for the cases you have mentioned in the description.
I was thinking, instead of assigning a list of protocol types, would it make
more sense to instead add some hierarchy to these protocols? So, for example,
the streams protocol type, despite being a new protocol, at its core still
would need to adhere to the consumer protocol type(which it already is). So, if
we can add this kind of a structure, then it can be made more extendable. Let
me know if this makes sense?
> Augment singleton protocol type to list for Kafka Consumer
> ------------------------------------------------------------
>
> Key: KAFKA-7995
> URL: https://issues.apache.org/jira/browse/KAFKA-7995
> Project: Kafka
> Issue Type: Improvement
> Components: consumer, core
> Reporter: Boyang Chen
> Assignee: Sagar Rao
> Priority: Major
> Labels: newbie
>
> Right now Kafka consumer protocol uses a singleton marker to distinguish
> Kafka Connect worker and normal consumer. This is not upgrade-friendly
> approach since the protocol type could potential change over time. A better
> approach is to support multiple candidacies so that the no downtime protocol
> type switch could achieve.
> For example, if we are trying to upgrade a Kafka Streams application towards
> a protocol type called "stream", right now there is no way to do this without
> downtime since broker will reject changing protocol type to a different one
> unless the group is back to empty. If we allow new member to provide a list
> of protocol type instead ("consumer", "stream"), there would be no
> compatibility issue.
> Alternative approach is to invent an admin API to change group's protocol
> type on runtime. However, the burden introduced on administrator is not
> trivial, since we need to guarantee the operation series to be correct,
> otherwise we will see limp-upgrade experience in the midpoint, for example
> while we are changing protocol type there was unexpected rebalance that
> causes old members join failure.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
