[
https://issues.apache.org/jira/browse/KAFKA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867763#comment-17867763
]
Lianet Magrans commented on KAFKA-17116:
----------------------------------------
Hey [~frankvicky] , sorry I missed this comment.
Your suggestion of the simple approach sounds good to me, to be explored. Given
that the issue is that we don't want to send the leave request if we don't have
a member id yet, we could consider:
* skip HB if leaving but no member ID (note the skip concept, I refer to
getting the same behaviour as when shouldSkipHeartbeat=true but in the the case
of state ==LEAVING and memberId==null. With the skip we ensure that it won't
wait the full HB interval to check again)
* this means that it may stay LEAVING for several poll cycles, until it gets a
member ID. But still, the leave request will only be sent out once, as usual.
* we should review the potential interactions (ex. consumer tries to join
again, while on this LEAVING that it's lingering for a bit waiting for a member
ID). I expect they will be fine, just because we already consider all that may
happen while LEAVING
Just from the top of the my head, but if it works, it would be a simple
approach so interesting.
> 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)
