DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
This KIP proposes adding a UUID called the client instance ID into the request header of all Kafka protocol requests. Those familiar with KIP-714 will be aware that it already introduced the client instance ID, so this KIP actually proposes elevating that concept to into a universal unique identifier for client instances in all RPCs.
...
By adding client instance ID to the request headers, we now had a unique application instance identifier which we can use for other purposes such as the member ID in the group protocols and the client telemetry client instance ID. The client MUST use the same UUID in request headers as it uses for the client telemetry client instance ID. The alignment of these other identifiers is by convention (and the Java client will follow the convention) rather than mandate. In the language of standards, the client SHOULD use the same UUID in request headers as it uses for the member ID in the group protocols and the client telemetry client instance ID. This alignment just makes traceability and problem determination more straightforward.
...
This KIP makes one change to the GetTelemetrySubscriptions behavior. If the client requests The client may only request a new client instance ID on its initial GetTelemetrySubscriptions request (request.clientInstanceId is 0) and also sends , if it does not also send a client instance ID in the request header. After this KIP, the broker will send back the is only expecting to generate telemetry client instance ID from the header for use with client telemetry rather than generating a new UUIDfor older clients which do not use the request header. This will automatically align the UUID in the request headers and client telemetry.
...
Client sends | Broker responds | Notes |
GetTelemetrySubscriptions v0 header.clientInstanceId not present request.ClientInstanceId = 0 | response.ClientInstanceId = UUID-B response.ErrorCode = NONE | This is KIP-714 initial The client is requesting a new client instance ID from the broker. The client will henceforth use UUID-B for client telemetry. |
GetTelemetrySubscriptions v0 header.ClientInstanceId = UUID-Hnot present request.ClientInstanceId = 0 UUID-R | response.ClientInstanceId = UUID-H0 response.ErrorCode = NONE | This is KIP-714 non-initial The client is requesting a new client instance ID from the broker, but it has sent UUID-H in the request header which the broker uses, thus aligning the client instance ID for the request headers and client telemetry. This is what we expect from the Apache Kafka Java client after this KIP. The client will henceforth use UUID-H for client telemetry. using UUID-R for client telemetry. |
GetTelemetrySubscriptions v0 header.ClientInstanceId not present= UUID-H request.ClientInstanceId = UUID-RH | response.ClientInstanceId = 0 response.ErrorCode = NONE | This is KIP-714 non-initial 714 The client is using UUID-RH for request headers and client telemetry. This is what we expect from the Apache Kafka Java client after this KIP. |
GetTelemetrySubscriptions v0 header.ClientInstanceId = UUID-H request | ||
.ClientInstanceId = 0 | response.ErrorCode = | |
INVALID_REQUEST | This is not allowed. If a client sends UUID-H in the request header, the request client instance ID must also be UUID-H. After this KIP, the client generates the client instance ID and does not ask the broker to do so | |
. | ||
GetTelemetrySubscriptions v0 header.ClientInstanceId = UUID-H request.ClientInstanceId = UUID-Rresponse.ClientInstanceId = 0-R≠UUID-H | response.ErrorCode = NONE INVALID_REQUEST | This is also KIP-714 non-initial If a client sends UUID-H in the request header, the request client instance ID must also be UUID-HFor some reason, the client is using UUID-H for request headers, but UUID-R for client telemetry. This is allowed, but not preferred. Included for completeness. |
In summary, for GetTelemetrySubscriptions v0, here are the combinations:
| Old broker | New broker | |
|---|---|---|
| Old client | Initial request:
Subsequent requests:
| Initial request:
Subsequent requests:
|
| New client | Initial request:
|
|
Subsequent requests:
|
| Initial request:
|
|
Subsequent requests:
|
Public Interfaces
Client API Changes
...
A very small behavioral change is made in the broker handling of GetTelemetrySubscriptions v0. If the client sends a zero GetTelemetrySubscriptions v0.
A post-KIP-1313 client will not send a zero ClientInstanceId in the request body to ask the broker to assign an ID.
If the client sends a zero ClientInstanceId in the request body, it must not send a ClientInstanceId in the request header.
Similarly, if the client sends a ClientInstanceId in the request body header and it also sends a non-zero ClientInstanceId in the request header, rather than generating a new UUID, the broker will respond with the ClientInstanceId from the request header. This naturally aligns the request header and client telemetry values for ClientInstanceId body, the values must be the same. It is not permitted to use one client instance ID for request headers and a different client instance ID for telemetry.
As a result, the description for the ClientInstanceId field in the request becomes "Unique id for this client instance. If a client is sending ClientInstanceId in the header, must equal that value. If not, must be set to 0 on the first request." .
Compatibility, Deprecation, and Migration Plan
...