[
https://issues.apache.org/jira/browse/KAFKA-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17859753#comment-17859753
]
Greg Harris commented on KAFKA-17001:
-------------------------------------
IMHO mutable config classes are undesirable, both for concurrency problems and
the inherent complexity.
In situations with "poll-based" reconfiguration, where we want a lazy update
whenever we ask for it, the mutability can be expressed via
`Supplier<AbstractConfig>`.
In situations with "push-based" reconfiguration, where we want an eager
callback whenever a reconfiguration takes place, the mutability can be
expressed via the `Reconfigurable` interface.
> 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)
