junrao commented on code in PR #19371:
URL: https://github.com/apache/kafka/pull/19371#discussion_r2096192551


##########
server-common/src/main/java/org/apache/kafka/server/config/ServerTopicConfigSynonyms.java:
##########
@@ -47,9 +48,11 @@ public final class ServerTopicConfigSynonyms {
      * both the first and the second synonyms are configured, we will use only 
the value of
      * the first synonym and ignore the second.
      */
-    // Topic configs with no mapping to a server config can be found in 
`LogConfig.CONFIGS_WITH_NO_SERVER_DEFAULTS`
     public static final Map<String, List<ConfigSynonym>> 
ALL_TOPIC_CONFIG_SYNONYMS = Utils.mkMap(
         sameNameWithLogPrefix(TopicConfig.SEGMENT_BYTES_CONFIG),
+        // Due to the internal.segment.bytes is in storage module, thus we 
could not use the 
+        // LogConfig#INTERNAL_SEGMENT_BYTES_CONFIG directly. We need to use 
the string value instead.
+        sameNameWithInternalLogPrefix("internal.segment.bytes"),

Review Comment:
   Is the intention to support `internal.segment.bytes` at the broker level? If 
so, should we add it to `KafkaConfig.extractLogConfigMap` too?
   
   Currently, if internal.log.segment.bytes is set at the broker, it won't be 
picked up by a new user topic, but it will be picked up by the kraft topic.
   
   Thinking a bit more. Do we need to support internal.segment.bytes at the 
broker level? For testing, is it enough to just support internal.segment.bytes 
at the topic level?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to