You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Boyang Chen (Jira)" <ji...@apache.org> on 2020/07/17 22:29:00 UTC

[jira] [Comment Edited] (KAFKA-10284) Group membership update due to static member rejoin should be persisted

    [ https://issues.apache.org/jira/browse/KAFKA-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160216#comment-17160216 ] 

Boyang Chen edited comment on KAFKA-10284 at 7/17/20, 10:28 PM:
----------------------------------------------------------------

If we have a combined scenario like below:
 # A static member X joins the group and updates member.id to M1, then gets stuck
 # Another static member Y with the same instance.id joins and updates member.id to M2, while starts working and commit offsets
 # The group coordinator migrates, and the member.id for the same static member rewinds to M1
 # The static member X goes back online, and validated. It would try to fetch from Y's committed offset

In this flow, I don't think we are violating the offset committing policy here. 

The only downside I could think of is that there is only one member Y who will get fenced by itself after the immigration as stated in the description. [~guozhang]


was (Author: bchen225242):
If we have a combined scenario like below:


 # A static member X joins the group and updates member.id to M1, then gets stuck
 # Another static member Y with the same instance.id joins and updates member.id to M2, while starts working and commit offsets
 # The group coordinator migrates, and the member.id for the same static member rewinds to M1
 # The static member X goes back online, and validated. It would try to fetch from Y's committed offset

In this flow, I don't think we are violating the offset committing policy here. 

The only downside I could think of is that there is only one member Y who will get fenced by itself after the immigration as stated in the KIP. [~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)