Table of Contents |
---|
Status
Current state: Under DiscussionAccepted
Discussion thread: here
JIRA:
Jira | ||||||||
---|---|---|---|---|---|---|---|---|
|
...
Code Block |
---|
DeleteGroups Request (Version: 0) => [group_id] group_id => STRING DeleteGroups Response (Version: 0) => throttle_time_ms [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 |
...
A --delete switch for the consumer group command tool (kafka-consumer-groups.sh
) will by supported for Kafka stored group offsets (new consumer) too, which behaves similar to its old consumer counterpart. For example, if group has active consumers the deletion will fail. In other words, a group can be deleted only when its state is Empty.
Similar to how the consumer group command line tool supports describing a single group at a time, the deletion functionality will be implemented the same way (deleting one group at a time). The protocol, however, support deleting multiple groups in one request.
Compatibility, Deprecation, and Migration Plan
The changes proposed by this KIP apply to the new Java-based consumer only, and are backward compatible because the suggested API does not already exist. New clients that work with older brokers will not be able to make use of this new API.
...
- 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.