[
https://issues.apache.org/jira/browse/KAFKA-8487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16861208#comment-16861208
]
ASF GitHub Bot commented on KAFKA-8487:
---------------------------------------
guozhangwang commented on pull request #6894: KAFKA-8487: Only request re-join
on REBALANCE_IN_PROGRESS in CommitOffsetResponse
URL: https://github.com/apache/kafka/pull/6894
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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
>
> 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)
