[
https://issues.apache.org/jira/browse/KAFKA-13612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17481400#comment-17481400
]
Dominic Evans commented on KAFKA-13612:
---------------------------------------
[~hachikuji] for context, it was first reported as an issue in 2.8 by a
linkedin/burrow user who was bootstrapping new deployments of kafka and burrow
alongside each other and it seems burrow had been relying on being able to send
a MetadataRequest at startup to determine the numbers of partitions of the
__consumer_offsets topic. I agree that it should be possible for burrow to
workaround the change in behaviour, although I note it has been this way since
the original KAFKA-1012 implementation
(https://github.com/apache/kafka/blob/a670537aa33732b15b56644d8ccc1681e16395f5/core/src/main/scala/kafka/server/KafkaApis.scala#L650-L652)
I _think_ the reason why the __consumer_offsets topic was special-cased (i.e.,
to ignore auto.create.topics being purposefully disabled) was simply, as an
internal topic, to ensure it was always available whenever anything asked for it
> 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)
