[
https://issues.apache.org/jira/browse/KAFKA-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053655#comment-17053655
]
Colin McCabe commented on KAFKA-9635:
-------------------------------------
If we want a change notification feature (and I think we do) then we need
something like these methods. But more design is probably needed to figure out
what else we need to make this work.
In any case, I think this discussion would be a better fit for the mailing list
than here, since it relates to a KIP.
> 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)
