[
https://issues.apache.org/jira/browse/KAFKA-17116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869396#comment-17869396
]
Chia-Ping Tsai commented on KAFKA-17116:
----------------------------------------
[~dajac] thanks for sharing the idea and details.
The basic idea is "client needs to know/have the uuid before member is added to
group". IMHO both solutions have pros and cons. However, the option_2: using
the first HB to get UUID from server needs to deal with the compatibility, as
the old server still add the member to the group when handling the first HB.
that is to say, the client needs to distinguish whether this member id is added
to group or not. otherwise, it may produces some weird log messages. By
contrast, the option_1 is non-invasive since our server can handle HB
with/without client-defined member id now. Also, the non-java client does not
need to change any code if they don't care for this edge case. If they does
care that edge case, python, golang, .net, and rust have built-in uuid support,
and there are many UUID impl for c++ (uuid_v4, boost's uuid, and uuid_v4).
Hence, I assume UUID support is not a big issue.
> 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)
