This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • KIP-88: OffsetFetch Protocol Update
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »


Current stateDiscussion

Discussion thread: here


Released: <Kafka Version>

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).


KAFKA-3853 asks for an improvement to the describe option of the consumer group command for new (Java API based) consumers. This command, when passed a consumer group that has no consumer (i.e., when the group state is Empty), currently reports an error indicating that there is no active member:

$ bin/ --new-consumer --bootstrap-server localhost:9092 --describe --group group1
Note: This will only show information about consumers that use the Java consumer API (non-ZooKeeper-based consumers).
Error: Consumer group 'group1' has no active members.

The requested improvement is returning offsets within the group (and leaving the consumer column empty) instead of returning the error message above. The error message can still be printed to to stderr as a warning.

When the group is Stable (i.e. when there are active consumers in the group), the above command returns the associated topic partition assignment for each member of the group, and that assignment can be used to extract the corresponding committed offset(s). However, if the group state is Empty (i.e. when there are no active consumers in the group) there is no associated topic partition info in DescribeGroups Response. Therefore, DescribeGroups Response in its current protocol would not help.

The OffsetFetch protocol can be used to extract offsets associated with given topic partitions in a consumer group. The problem is, when consumer group is in Empty state or even when it is Stable but not all its topics are being consumed, currently there is no way to extract all its topic partitions that it has consumed from so far. We can modify the behavior of OffsetFetch protocol so it returns all topic partitions associated with the group if it is passed an empty list (as the list of topic partitions). 

Public Interfaces

This is the current schema for OffsetFetch (version 1, that applies to fetching from Kafka, and not ZooKeeper).

OffsetFetch Request (Version: 1) => group_id [topics] 
  group_id => STRING
  topics => topic [partitions] 
    topic => STRING
    partitions => partition 
      partition => INT32
OffsetFetch Response (Version: 1) => [responses] 
  responses => topic [partition_responses] 
    topic => STRING
    partition_responses => partition offset metadata error_code 
      partition => INT32
      offset => INT64
      metadata => NULLABLE_STRING
      error_code => INT16

The first suggestion is to use the same Request / Response protocol but bump up the version to 2 since there is going to be a change in how the protocol is implemented. What will change in the protocol implementation is if an empty list is passed instead of a list of topic partitions the API will return the offsets of all topic partitions associated with the group.

The second suggestion has to do with how the above API is accessed and called. Currently, the way the offset information for each topic partition in a Stable group is returned is through creating a "dummy" consumer in the group and use its committed interface to extract those offset information:

val consumer = getConsumer()
... consumer.committed(new TopicPartition(topicPartition.topic, topicPartition.partition)) ...

This committed call makes use of the OffsetFetch API to extract the offset of the given partition. The suggestion here is to add a method to AdminClient that extracts offset information of a consumer group by making a call to OffsetFetch API, and passing an empty list of topic partitions. That will return all offsets of topic partitions associated with the consumer's group:

def listGroupOffsets(groupId: String): Map[TopicPartition, PartitionData] = {
 val coordinator = findCoordinator(groupId)
 val responseBody = send(coordinator, ApiKeys.OFFSET_FETCH, new OffsetFetchRequest(groupId, List()))
 val response = responseBody.asInstanceOf[OffsetFetchResponse]

One benefit of using this method instead of using the KafkaConsumer's committed method is that we no longer need to create the dummy consumer to retrieve offsets. The other benefit here is that with one API call all offsets within the group are returned. Whereas, in the existing describe group implementation, for each topic partition in the group one API call is made.

Proposed Changes

The proposal is to

  1. Add to the implementation of the OffsetFetch API the scenario where an empty list is passed as the list of topic partitions, and in response, offsets of all topic partitions associated with the group are returned.
  2. Add a listGroupOffsets interface to AdminClient that makes use of the updated OffsetFetch API above and returns offsets of all topic partitions associated with the consumer's group. 


Compatibility, Deprecation, and Migration Plan

With respect to the first proposed change above the compatibility could become a concern if current users somehow rely on a different behavior when an empty list is passed to the OffsetFetch API as the list of topic partitions. If users would want to stick to the current implementation of the API they can use version 1 of the API. The change suggested in this KIP would apply to version 2 of the API only.

With respect to the added interface to AdminClient there would be no issue as that interface does not exist in current implementation.

Rejected Alternatives

  1. Changing the DescribeGroups protocol so it also returns the offset information for all topic partitions from which the group has consumed from since its creation. More detailed can be found here.
  2. Exposing the added OffsetFetch behavior through a new interface in KafkaConsumer, which would still imply that the dummy consumer has to be created in the group in order to retrieve offsets.  More details can be found here.
  • No labels