[ https://issues.apache.org/jira/browse/KAFKA-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17859766#comment-17859766 ]
Greg Harris commented on KAFKA-17001: ------------------------------------- [~chia7712] That sounds reasonable. The Supplier.get implementation can be very lightweight, like AtomicReference::get. > Consider using another class to replace `AbstractConfig` to be class which > always returns the up-to-date configs > ---------------------------------------------------------------------------------------------------------------- > > Key: KAFKA-17001 > URL: https://issues.apache.org/jira/browse/KAFKA-17001 > Project: Kafka > Issue Type: Improvement > Reporter: Chia-Ping Tsai > Assignee: Chia-Ping Tsai > Priority: Minor > > from https://github.com/apache/kafka/pull/16394#discussion_r1647321514 > We are starting to have separate config class ( i.e RemoteLogManagerConfig), > and those configs will be initialized with a AbstractConfig. By calling > `AbstractConfig' getters, those individual configs can always return the > up-to-date configs. Behind the magic behavior is the instance of > `AbstractConfig` ... yes, we use the `KafkaConfig` to construct those config > classes. We call `KafkaConfig#updateCurrentConfig` to update inner configs, > so those config classes which using `AbstractConfig` can see the latest > configs too. > However, this mechanism is not readable from `AbstractConfig`. Maybe we > should add enough docs for it. Or we can > move`KafkaConfig#updateCurrentConfig` into a new class with better naming. -- This message was sent by Atlassian Jira (v8.20.10#820010)