[
https://issues.apache.org/jira/browse/KAFKA-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17164146#comment-17164146
]
Akshay Sharma commented on KAFKA-10284:
---------------------------------------
At initial, Group Coordinator will assign member id to the new joined consumer
i.e X with generation id 1, when the consumer take off at the same point and
try to rejoin there be no re-balance(i.e generation id will be 1), but group
coordinator will assign new member id to the consumer i.e Y. Now, when broker
restart due to some reason, groupmetadatamanager will reload the metadata and
expects that member.id to be present, he is now expecting X member.id. and
that's why consumer is fenced.
1) Is this a expected behaviour?
2) when consumer member id changes, groupmetadatamanager not updates new
member.id information?
3) consumer is fenced with new instance, even single consumer is running. Why?
[~bchen225242] [~guozhang]
> Group membership update due to static member rejoin should be persisted
> -----------------------------------------------------------------------
>
> Key: KAFKA-10284
> URL: https://issues.apache.org/jira/browse/KAFKA-10284
> Project: Kafka
> Issue Type: Bug
> Components: consumer
> Affects Versions: 2.3.0, 2.4.0, 2.5.0, 2.6.0
> Reporter: Boyang Chen
> Assignee: Boyang Chen
> Priority: Major
> Fix For: 2.6.1
>
>
> For known static members rejoin, we would update its corresponding member.id
> without triggering a new rebalance. This serves the purpose for avoiding
> unnecessary rebalance for static membership, as well as fencing purpose if
> some still uses the old member.id.
> The bug is that we don't actually persist the membership update, so if no
> upcoming rebalance gets triggered, this new member.id information will get
> lost during group coordinator immigration, thus bringing up the zombie member
> identity.
> The bug find credit goes to [~hachikuji]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
