...
Code Block |
---|
DeleteGroups Request (Version: 0) => [group_id] group_id => STRING DeleteGroups Response (Version: 0) => throttle_time_ms error_code [group_error_codes] throttle_time_ms => INT32 error_code => INT16 group_error_codes => group_id error_code group_id => STRING error_code => INT16 |
Protocol | Field | Description |
---|---|---|
Request | group_id | The unique group identifier |
Response | throttle_time_ms | Duration in milliseconds for which the request was throttled due to quota violation (Zero if the request did not violate any quota) |
error_code | Response error code | |
group_error_codes | ||
group_id | The unique group identifier | |
error_code | Error code corresponding to the individual group_id |
...
- Using the newly introduced offset reset functionality of the consumer group command tool by injecting a
retention_time
of 0: This alternative was rejected in favor of KIP-211, that aims at removing theretention_time
field from theOffsetCommit
API. - Exposing the group deletion functionality in
org.apache.kafka.clients.admin.AdminClient
: This was left as a future work as no group-related functionality has been implemented inAdminClient
yet. - Providing the functionality to delete individual offsets: This was also left as a potential future work to keep the initial implementation simple. If, in the future, it turns out that per-partition offset reset is not sufficient and there is a need to delete individual offsets, it can be proposed and implemented in its own KIP.
- Having a high level error code in the response protocol: This was rejected because one error code cannot normally be generalized to all groups that are requested be deleted. It may very well be the case that a
Errors.COORDINATOR_NOT_AVAILABLE
error would apply to some groups (groups to be deleted may belong to different coordinators),Errors.GROUP_AUTHORIZATION_FAILED
would apply to some other, etc.