[ https://issues.apache.org/jira/browse/KAFKA-13612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482115#comment-17482115 ]
Dominic Evans commented on KAFKA-13612: --------------------------------------- [~hachikuji] I have no affiliation with Burrow, but I can wager a guess as to why they choose to read from __consumer_offsets directly. If you're writing any software to monitor the lag of Kafka Consumer groups, it's much more efficient to be asynchronously driven by the changes to the `__consumer_offsets` partitions than it is to repeatedly poll the Kafka API, cache results and manage evictions yourself. Option 1: read from __consumer_offsets and parse the data format yourself Option 2: * poll every broker in the cluster with ListGroupsRequests * send FindCoordinator requests for every group and put them in batches * send DescribeGroupRequest to each coordinator with the batches of consumer groups * read the results out of the DescribeGroupResponses and go round the loop again > internal topics won't be created in metadataRequest when > auto.create.topics.enable=false > ---------------------------------------------------------------------------------------- > > Key: KAFKA-13612 > URL: https://issues.apache.org/jira/browse/KAFKA-13612 > Project: Kafka > Issue Type: Bug > Affects Versions: 2.8.0, 3.0.0 > Reporter: Luke Chen > Assignee: Luke Chen > Priority: Major > > In KAFKA-9751, when create internal topics through FindCoordinator or > Metadata request, we route the topic creation request to the controller > instead of handling by itself. We change logic in > `KafkaApis#getTopicMetadata`, and make the internal topic won't get created > when "auto.create.topics.enable=false`. > h4. -- This message was sent by Atlassian Jira (v8.20.1#820001)