[
https://issues.apache.org/jira/browse/KAFKA-20601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jacot resolved KAFKA-20601.
---------------------------------
Fix Version/s: 4.4.0
4.3.2
Resolution: Fixed
> ConsumerGroup static member rejoin can fail with GroupMaxSizeReachedException
> at max size
> -----------------------------------------------------------------------------------------
>
> Key: KAFKA-20601
> URL: https://issues.apache.org/jira/browse/KAFKA-20601
> Project: Kafka
> Issue Type: Bug
> Reporter: sanghyeok An
> Assignee: sanghyeok An
> Priority: Minor
> Fix For: 4.4.0, 4.3.2
>
>
> GroupMetadataManager#throwIfConsumerGroupIsFull() only checks whether the
> provided memberId already exists in the group:
> {code:java}
> group.numMembers() >= config.consumerGroupMaxSize()
> && (memberId.isEmpty() || !group.hasMember(memberId))
> {code}
> However, when a static member rejoins after leaving with the static leave
> epoch (-2), the rejoining member may use a new member ID. In that case, the
> existing static member is identified by instanceId, not by the new memberId.
> Because the max-size check runs before resolving/replacing the static member,
> a valid static member rejoin can be rejected with
> GroupMaxSizeReachedException when the group is already at max size, even
> though the operation would replace an existing static member and would not
> increase the group size.
> *Expected behavior*
> A static member rejoin for an existing instanceId should not fail the
> max-size check solely because the rejoining memberId is new or empty. The
> check should account for existing static members, similar to checking
> group.hasStaticMember(instanceId).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
