THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
| Code Block |
|---|
DeleteGroups Request (Version: 0) => [group_id] group_id => STRING DeleteGroups Response (Version: 0) => throttle_time_ms error_code [group_error_codesresponses] throttle_time_ms => INT32 errorgroup_coderesponses => 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_codesresponses | ||
| 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_timeof 0: This alternative was rejected in favor of KIP-211, that aims at removing theretention_timefield from theOffsetCommitAPI. - 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 inAdminClientyet. - 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_AVAILABLEerror would apply to some groups (groups to be deleted may belong to different coordinators),Errors.GROUP_AUTHORIZATION_FAILEDwould apply to some other, etc.