DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
If a client does not specify a client instance ID in the request header of its first request which uses the v2 request header, it must not specify a client instance ID in the request header of any subsequent requests. If it does so, the request will be rejected with error code INVALID_REQUEST.
Alignment of identifiers
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 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.
It would be possible to go around the existing RPCs such as ConsumerGroupHeartbeat and GetTelemetrySubscriptions , and remove the fields containing the existing identifiers which are intended to be aligned. Doing so would be a bad idea though, because we would then have RPC versions which essentially depend upon the presence of a tagged field in the request header. This is a protocol-compatibility nightmare.
This KIP makes one change to the GetTelemetrySubscriptions behavior. If the client requests a new client instance ID on its initial GetTelemetrySubscriptions request
...
(request.clientInstanceId is 0) and also sends a client instance ID in the request header, the broker will send back
...
the client instance ID from the header for use with client telemetry rather than generating a new UUID. This will automatically align the UUID in the request headers and client telemetry.
Key:
- UUID-H - client instance ID sent by client in header, generated by client
- UUID-R - client instance ID sent by client in request, which is not equal to UUID-H
- UUID-B - client instance ID sent by broker in response, generated by broker
Pre-KIP-1313 - broker does not expect ClientInstanceId in request header and ignores it
Client sends | Broker responds | Notes |
GetTelemetrySubscriptions v0 request.ClientInstanceId = 0 | response.ClientInstanceId = UUID-B response.ErrorCode = NONE | This is KIP-714 initial Client is requesting a new client instance ID from the broker. The client will henceforth use UUID-B for client telemetry. |
GetTelemetrySubscriptions v0 request.ClientInstanceId = UUID-R | response.ClientInstanceId = 0 response.ErrorCode = NONE | This is KIP-714 non-initial The client is using UUID-R for client telemetry. |
Post-KIP-1313 - broker is aware of optional ClientInstanceId in request header
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-H request.ClientInstanceId = 0 | response.ClientInstanceId = UUID-H response.ErrorCode = NONE | This is KIP-714 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. |
GetTelemetrySubscriptions v0 header.ClientInstanceId not present request.ClientInstanceId = UUID-R | response.ClientInstanceId = 0 response.ErrorCode = NONE | This is KIP-714 non-initial The client is using UUID-R for client telemetry. |
GetTelemetrySubscriptions v0 header.ClientInstanceId = UUID-H request.ClientInstanceId = UUID-H | response.ClientInstanceId = 0 response.ErrorCode = NONE | This is KIP-714 non-initial The client is using UUID-H 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 = UUID-R | response.ClientInstanceId = 0 response.ErrorCode = NONE | This is also KIP-714 non-initial For 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
...