[jira] [Resolved] (KAFKA-9635) Should ConfigProvider.subscribe be deprecated?

["Colin McCabe (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colin McCabe resolved KAFKA-9635.
---------------------------------
    Resolution: Duplicate

Let's continue the discussion on the mailing list.

> 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)