Hi Apoorv, Thanks for your suggestion. AM1: That's a great idea. Done.
Thanks, Andrew On 2026/04/27 12:24:12 Apoorv Mittal wrote: > Hi Andrew, > Thanks for the KIP. I have one question: > > AM1: With KIP-1082, the consumer now generates its own member ID at > construction time. With KIP-1313, the client will generate its own client > instance ID as a Uuid at construction time. Both are client-generated > UUIDs, immediately available at startup, and remain constant for the > process's lifetime. For a consumer (or share consumer), these two IDs serve > overlapping identification purposes at the same scope: identifying this > particular client incarnation. The ClientInstanceIds interface in Streams > already maintains a separate client instance ID per consumer per thread, so > there is no cardinality mismatch even in multi-threaded Streams > applications. Has unifying these been considered? The consumer could > generate one UUID at startup and use it both as its member ID in heartbeat > requests and as the client instance ID in request headers and telemetry. > > Regards, > Apoorv Mittal > > > On Fri, Apr 24, 2026 at 5:48 PM Jun Rao via dev <[email protected]> > wrote: > > > Hi, Andrew, > > > > Thanks for the reply. > > > > JR1. Caching the clientID from the first request in ChannelMetadataRegistry > > sounds good. We can then use it to fill the request header in subsequent > > requests. > > > > JR2.1 Ok. It's fine to include clientInstanceID in the request header. It > > would be useful to document that it's only set on the first request and > > cached in ChannelMetadataRegistry. > > > > Jun > > > > On Fri, Apr 24, 2026 at 6:28 AM Andrew Schofield <[email protected]> > > wrote: > > > > > Hi Jun, > > > Thanks for your comments. > > > > > > JR1: I was thinking of attaching it to some channel-based context, such > > as > > > the ChannelMetadataRegistry. I've not dug into the code in detail at this > > > point. However, as mentioned in the KIP, removing the client ID from all > > > except the initial request is perhaps overreach in this KIP. I wonder > > > whether actually this would be better handled in a major release. Let me > > > know your thoughts here. > > > > > > JR2.1: I did consider put it in the ApiVersionsRequest, but I do want it > > > in every request to help with problem diagnosis. Also, ApiVersions is > > not a > > > mandatory part of the protocol, so we can't rely on it being the first > > > request. > > > > > > JR2.2: Similar to JR1, I was thinking of hanging it off some > > channel-based > > > context. > > > > > > JR3: Indeed. I've added share consumer. > > > > > > JR4: Thinking about migration more, it seems to me that it is best not to > > > introduce new versions of the PushTelemetry and GetTelemetrySubscriptions > > > RPCs. For an AK 4.4 Java client, we know that the client will generate a > > > client instance ID before its initial connection. For any other client, > > we > > > do not know that. Consequently, even in the broker supports a newer > > version > > > of PushTelemetry which omits ClientInstanceId from the request schema, we > > > would still need to support the broker-side ClientInstanceId > > initialization > > > in which the response contains the ID created by the broker. I think that > > > leaving the slightly redundant ClientInstanceId in the KIP-714 RPCs is > > > best. I've changed the text accordingly. Let me know what you think. > > > > > > Thanks, > > > Andrew > > > > > > On 2026/04/23 19:04:37 Jun Rao via dev wrote: > > > > Hi, Andrew, > > > > > > > > Thanks for the KIP. A few comments. > > > > > > > > JR1. Currently, you can configure a client quota based on > > > > clientId. Currently, the broker extracts the clientId from the request > > > > header. If clientId is not included in every request, can we document > > > where > > > > the server will obtain it? > > > > > > > > JR2. client instance ID: > > > > JR2.1 Is it only sent on the first request in a connection? If so, have > > > we > > > > considered making it part of the ApiVersionRequest instead of the > > request > > > > header? > > > > JR2.2 It would be useful to include the client instance ID in request > > > > logging on the server side. Could we document how to make that > > available > > > > for each request the server processes? > > > > > > > > JR3. "The client instance ID will be calculated during the constructor > > of > > > > the Producer , Consumer and Admin". > > > > What about ShareConsumer? > > > > > > > > JR4. GetTelemetrySubscriptions: Could we document the changes in the > > > > response too? > > > > > > > > Jun > > > > > > > > > > > > On Fri, Apr 3, 2026 at 9:18 AM Andrew Schofield < > > > [email protected]> > > > > wrote: > > > > > > > > > Hi, > > > > > I would like to start the discussion on KIP-1313. This adds a unique > > > > > client instance ID to the request header of all Kafka protocol > > > requests to > > > > > give a unique identifier which can be used to correlate the requests > > > from > > > > > each client for the purposes of problem determination. > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/KAFKA/KIP-1313*3A*Client*instance*ID*in*all*request*headers__;JSsrKysrKys!!Ayb5sqE7!txpES9zmXlCh8usguNsiJLRnSXvMtgWuM6R1rx8VxYYyi-sThQTmaOrq3ZfhArG25CjhHKuaLaJ63z_dzny8$ > > > > > > > > > > Thanks, > > > > > Andrew > > > > > > > > > > > > > > >
