You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by "Tom Bentley (Jira)" <ji...@apache.org> on 2020/03/02 15:49:00 UTC

[jira] [Created] (KAFKA-9635) Should ConfigProvider.subscribe be decrecated?

Tom Bentley created KAFKA-9635:
----------------------------------

             Summary: Should ConfigProvider.subscribe be decrecated?
                 Key: KAFKA-9635
                 URL: https://issues.apache.org/jira/browse/KAFKA-9635
             Project: Kafka
          Issue Type: Bug
            Reporter: Tom Bentley
            Assignee: Tom Bentley


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)