[
https://issues.apache.org/jira/browse/KAFKA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867801#comment-17867801
]
Chia-Ping Tsai commented on KAFKA-17116:
----------------------------------------
The close is invoked by users and the close needs to honor the timeout, so what
if consumer can't get response to see memberId in time?
1)
If we decide to wait for the response to send LEAVE request in closing, we need
to update the docs of close(Duration) to explain this behavior: this close
could get blocked until we get the response of member id.
2)
If we decide to skip the LEAVE request due to user-defined timeout, then broker
will have a registered new member
It seems to me that is a trade-off. Either way will have side effect. Maybe we
should have a way to remove the registered member according to other fields.
For example:
1. consumer can add a tagged specific id to HB request and then consumer can
use the specific id to remove registered member. the specific id is optional so
it can keep compatibility. Also, the specific id is used only if consumer is
closing and it can't wait for response of member id.
2. use other fields to generate "unique" id and broker can remove registered
member when member id is -1. This does not change the protocol data, but not
sure how to create a unique id by the other fields
> 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)
