You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Guozhang Wang (JIRA)" <ji...@apache.org> on 2019/06/11 17:19:00 UTC

[jira] [Resolved] (KAFKA-8487) Consumer should not resetGeneration upon REBALANCE_IN_PROGRESS in commit response handler

     [ https://issues.apache.org/jira/browse/KAFKA-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guozhang Wang resolved KAFKA-8487.
----------------------------------
       Resolution: Fixed
    Fix Version/s: 2.4.0

> Consumer should not resetGeneration upon REBALANCE_IN_PROGRESS in commit response handler
> -----------------------------------------------------------------------------------------
>
>                 Key: KAFKA-8487
>                 URL: https://issues.apache.org/jira/browse/KAFKA-8487
>             Project: Kafka
>          Issue Type: Bug
>          Components: consumer, streams
>    Affects Versions: 2.3.0
>            Reporter: Guozhang Wang
>            Assignee: Guozhang Wang
>            Priority: Blocker
>             Fix For: 2.4.0
>
>
> In consumer, we handle the errors in sync / heartbeat / join response such that:
> 1. UNKNOWN_MEMBER_ID / ILLEGAL_GENERATION: we reset the generation and request re-join.
> 2. REBALANCE_IN_PROGRESS: do nothing if a rejoin will be executed, or request re-join explicitly.
> However, for commit response, we require resetGeneration for REBALANCE_IN_PROGRESS as well. This is a flaw in two folds:
> 1. As in KIP-345, with static members, reseting generation will lose the member.id and hence may cause incorrect fencing.
> 2. As in KIP-429, resetting generation will cause partitions to be "lost" unnecessarily before re-joining the group. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)