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. Best, Boyang ________________________________ From: Ismael Juma <isma...@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 Hi, 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. Ismael On Mon, Nov 26, 2018, 5:48 PM Boyang Chen <bche...@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 >
