[
https://issues.apache.org/jira/browse/KAFKA-13765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511546#comment-17511546
]
Ryan Leslie commented on KAFKA-13765:
-------------------------------------
[~guozhang] Are you referring to KafkaAdminClient.describeConsumerGroups(), or
just something like the kafka-consumer-groups.sh wrapper? If it's the admin
client, we may need to be extra careful not to make a backward incompatible API
change, like in KAFKA-12879. For example, if someone is relying on the admin
client to monitor consumer group members then this change might affect such an
application by causing an unexpected dip in the results during rebalances.
While I agree it's unknown if all members will rejoin, most will in most cases,
and subsequent calls to describe the consumer group would eventually reveal
this. If we do want to support a different behavior, perhaps consider making it
optional in DescribeConsumerGroupsOptions. Also, a user today can simply
disregard the result themselves by checking ConsumerGroupDescription.state().
They can choose to retry later if they are only interested in seeing the group
in a stable state.
> Describe-consumer admin should not return unstable membership information
> -------------------------------------------------------------------------
>
> Key: KAFKA-13765
> URL: https://issues.apache.org/jira/browse/KAFKA-13765
> Project: Kafka
> Issue Type: Bug
> Components: admin
> Reporter: Guozhang Wang
> Priority: Major
>
> When a consumer group is in the “prepare-rebalance” phase, it's unclear if
> all its currently registered members would still be re-joining in the new
> generation or not, in this case, if we simply return the current members map
> to the describe-consumer request it may be misleading as users would be
> getting spurious results that may contain those dropping or even zombie
> consumers.
> So I think during the prepare-rebalance phase, we should either only return
> members who's join-group requests have already been received, OR we simply
> return the response with no members and indicate that via prepare-rebalance
> state the membership info is unstable and hence won't be returned.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
