[
https://issues.apache.org/jira/browse/KAFKA-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Bentley updated KAFKA-9635:
-------------------------------
Summary: Should ConfigProvider.subscribe be deprecated? (was: Should
ConfigProvider.subscribe be decrecated?)
> Should ConfigProvider.subscribe be deprecated?
> ----------------------------------------------
>
> Key: KAFKA-9635
> URL: https://issues.apache.org/jira/browse/KAFKA-9635
> Project: Kafka
> Issue Type: Bug
> Reporter: Tom Bentley
> Assignee: Tom Bentley
> Priority: Minor
>
> KIP 297 added the ConfigProvider interface for use with Kafka Connect.
> Its seems that at that time it was anticipated that config providers should
> have a change notification mechanism to facilitate dynamic reconfiguration.
> This was realised by having `subscribe()`, `unsubscribe()` and
> `unsubscribeAll()` methods in the ConfigProvider interface.
> KIP-421 subsequently added the ability to use config providers with other
> configs (e.g. client, broker and Kafka Streams). KIP-421 didn't end up using
> the change notification feature, since it was incompatible with being able to
> update broker configs atomically.
> As things currently stand the `subscribe()`, `unsubscribe()` and
> `unsubscribeAll()` methods remain in the ConfigProvider interface but are
> not used anywhere in the Kafka code base. Is there an intention to make use
> of these methods, or should they be deprecated?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
