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 > > > > > >
