You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Dongjin Lee (Jira)" <ji...@apache.org> on 2021/04/04 10:18:00 UTC
[jira] [Updated] (KAFKA-12613) Inconsistencies between Kafka Config
and Log Config
[ https://issues.apache.org/jira/browse/KAFKA-12613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dongjin Lee updated KAFKA-12613:
--------------------------------
Description:
I found this problem while investigating KAFKA-8926.
Some broker-wide configurations (defined in KafkaConfig) are mapped with log-wide configurations (defined in LogConfig), providing a default value. You can find the complete mapping list in `LogConfig.TopicConfigSynonyms`.
The problem is, *some configuration properties' validation is different between KafkaConfig and LogConfig*:
!20210404-161832.png!
These inconsistencies cause some problems with the dynamic configuration feature. When a user dynamically configures the broker configuration with `AdminClient#alterConfigs`, the submitted config is validated with KafkaConfig, which lacks some validation logic - as a result, they bypasses the correct validation.
For example, the user can set `log.cleaner.min.cleanable.ratio` to -0.5 - which is obviously prohibited in LogConfig.
* I could not reproduce the situation KAFKA-8926 describes, but fixing this problem also resolves KAFKA-8926.
was:
I found this problem while investigating KAFKA-8926.
Some broker-wide configurations (defined in KafkaConfig) are mapped with log-wide configurations (defined in LogConfig), providing a default value. You can find the complete mapping list in `LogConfig.TopicConfigSynonyms`.
The problem is, *some configuration properties' validation is different between KafkaConfig and LogConfig*:
!20210404-161832.png!
These inconsistencies cause some problems with the dynamic configuration feature. When a user dynamically configures the broker configuration with `AdminClient#alterConfigs`, the submitted config is validated with KafkaConfig, which lacks some validation logic - as a result, they bypasses the correct validation.
For example, the user can set `log.cleaner.min.cleanable.ratio` to 0.0 or -0.5 - which is obviously meaningless.
* I could not reproduce the situation KAFKA-8926 describes, but fixing this problem also resolves KAFKA-8926.
> Inconsistencies between Kafka Config and Log Config
> ---------------------------------------------------
>
> Key: KAFKA-12613
> URL: https://issues.apache.org/jira/browse/KAFKA-12613
> Project: Kafka
> Issue Type: Bug
> Components: core
> Reporter: Dongjin Lee
> Assignee: Dongjin Lee
> Priority: Major
> Attachments: 20210404-161832.png
>
>
> I found this problem while investigating KAFKA-8926.
> Some broker-wide configurations (defined in KafkaConfig) are mapped with log-wide configurations (defined in LogConfig), providing a default value. You can find the complete mapping list in `LogConfig.TopicConfigSynonyms`.
> The problem is, *some configuration properties' validation is different between KafkaConfig and LogConfig*:
> !20210404-161832.png!
> These inconsistencies cause some problems with the dynamic configuration feature. When a user dynamically configures the broker configuration with `AdminClient#alterConfigs`, the submitted config is validated with KafkaConfig, which lacks some validation logic - as a result, they bypasses the correct validation.
> For example, the user can set `log.cleaner.min.cleanable.ratio` to -0.5 - which is obviously prohibited in LogConfig.
> * I could not reproduce the situation KAFKA-8926 describes, but fixing this problem also resolves KAFKA-8926.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)