[
https://issues.apache.org/jira/browse/KAFKA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869739#comment-17869739
]
Chia-Ping Tsai commented on KAFKA-17116:
----------------------------------------
{quote}
If the above two statements are true, what's the downside of letting the broker
handle the member as it does today, namely removing it after some configured
amount of time?
{quote}
yes, tow statements are true! I quote [~lianetm]'s comments "those partitions
won't be re-assigned (broker waiting for the closed consumer to reconcile
them), until the rebalance timeout expires. "
{quote}
I agree that it makes sense to augment the client logic to only send the 'leave
group' request if we have a member ID. At this point, I'm -1 on the idea of
introducing temporary IDs to handle edge cases like this.
{quote}
I also hate temporary ID after see the suggestions from [~dajac] :smile
Also, I don't want to introduce large changes to just fix the edge case. That
is why I prefer the approach of letting `AsyncConsumer` generate UUID for
member Id
> New consumer may not send effective leave group if member ID received after
> close
> ----------------------------------------------------------------------------------
>
> Key: KAFKA-17116
> URL: https://issues.apache.org/jira/browse/KAFKA-17116
> Project: Kafka
> Issue Type: Bug
> Components: clients, consumer
> Affects Versions: 3.8.0
> Reporter: Lianet Magrans
> Assignee: TengYao Chi
> Priority: Major
> Labels: kip-848-client-support
> Fix For: 3.9.0
>
>
> If the new consumer is closed after sending a HB to join, but before
> receiving the response to it, it will send a leave group request but without
> member ID (will simply fail with UNKNOWN_MEMBER_ID). This will make that the
> broker will have a registered new member, for which it will never receive a
> leave request for it.
> # consumer.subscribe -> sends HB to join, transitions to JOINING
> # consumer.close -> will transition to LEAVING and send HB with epoch -1
> (without waiting for in-flight requests)
> # consumer receives response to initial HB, containing the assigned member
> ID. It will simply ignore it because it's not in the group anymore
> (UNSUBSCRIBED)
> Note that the expectation, with the current logic, and main downsides of this
> are:
> # If the case was that the member received partitions on the first HB, those
> partitions won't be re-assigned (broker waiting for the closed consumer to
> reconcile them), until the rebalance timeout expires.
> # Even if no partitions were assigned to it, the member will remain in the
> group from the broker point of view (but not from the client POV). The member
> will be eventually kicked out for not sending HBs, but only when it's session
> timeout expires.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
