Page History

Status

Current state: Under DiscussionAccepted

Discussion thread: here

JIRA:

...

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

...

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.

...

1. 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 the retention_time field from the OffsetCommit API.
2. 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 in AdminClient yet.
3. 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.
4. 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.