Hi Kirk,
Thanks for your feedback.

1. The clientInstanceId is just a UUID. If client ID is non-null, it's a string 
and could be quite chunky. I do accept that the change to client ID in this KIP 
is probably the most contentious part because it's not necessary for the 
principal intent of this KIP.

2. In Kafka Streams, each of the embedded clients (producer, consumer, admin) 
will have its own clientInstanceId. There is no separate clientInstanceId for 
the "logical" client which pulls them together. There could be, but that's not 
currently part of the KIP.

3. Because clientInstanceId is a tagged field in v2 of the request header, it 
applies to the latest versions of almost all of the RPCs. If you look at 
o.a.k.common.message.ApiMessageType.requestHeaderVersion(short), you'll see the 
mapping. The alternative of defining v3 of the RequestHeader would have 
necessitated a version bump of every RPC we wanted to have the new header 
version.

Thanks,
Andrew

On 2026/04/17 23:50:50 Kirk True wrote:
> Thanks for the KIP Andrew!
> 
> Some questions:
> 
>  1. Why is it preferable to send the client ID only on the initial request 
> but the client instance ID on every request?
>  2. Are "logical" clients (e.g. Kafka Streams) also assigned a client 
> instance ID? If so, how does its client instance ID relate to the embedded 
> clients’ instance IDs?
>  3. Is there any advice on "adoption" of the new client instance ID on the 
> broker side? I could see a situation where some RPCs end up using the client 
> instance ID, but not others.
> Thanks,
> Kirk
> 
> On Fri, Apr 3, 2026, at 9:17 AM, Andrew Schofield 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://cwiki.apache.org/confluence/display/KAFKA/KIP-1313%3A+Client+instance+ID+in+all+request+headers
> > 
> > Thanks,
> > Andrew
> > 
> 

Reply via email to