kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boyang Chen <bche...@outlook.com>
Subject Re: [DISCUSS] KIP-394: Require member.id for initial join group request
Date Sun, 20 Jan 2019 23:54:27 GMT
Hey Ismael,

thanks for the suggestion here! I think the reason is because creating individual id on client
is purely random (or at least I couldn't think of how to make sure it is "known to be unique").
Id collision will not be handled gracefully as we could perceive.

However let client generate unique id is a very good idea, which we proposed in KIP-345<https://cwiki.apache.org/confluence/display/KAFKA/KIP-345%3A+Introduce+static+membership+protocol+to+reduce+consumer+rebalances>
to let end user supply instance identities. This could save us one round-trip time to solve
member identity problem. Since enabling new feature requires user operation that is not guaranteed
to happen, KIP-394 is a patch to alleviate the similar issue for existing consumer use cases.


From: Ismael Juma <ismaelj@gmail.com>
Sent: Monday, January 21, 2019 6:07 AM
To: dev
Subject: Re: [DISCUSS] KIP-394: Require member.id for initial join group request


I'm late to the discussion, so apologies. One question, did we consider
having the client generate a member id in the first join group? This could
be random or known to be unique and would avoid a second join group request
in the common case. If we considered and rejected this option, it would be
good to include why in the "Rejected Alternatives" section.


On Mon, Nov 26, 2018, 5:48 PM Boyang Chen <bchen11@outlook.com wrote:

> Hey friends,
> I would like to start a discussion thread for KIP-394 which is trying to
> mitigate broker cache bursting issue due to anonymous join group requests:
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-394%3A+Require+member.id+for+initial+join+group+request
> Thanks!
> Boyang

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message