You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "SuryaTeja Duggi (JIRA)" <ji...@apache.org> on 2019/05/22 22:27:00 UTC
[jira] [Commented] (KAFKA-7995) Augment singleton protocol type to
list for Kafka Consumer
[ https://issues.apache.org/jira/browse/KAFKA-7995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16846263#comment-16846263 ]
SuryaTeja Duggi commented on KAFKA-7995:
----------------------------------------
[~bchen225242] Can i pick this up I am new. Could you add me to mailing list.
> 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
> 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)