somandal commented on code in PR #16823:
URL: https://github.com/apache/pinot/pull/16823#discussion_r2353116947
##########
pinot-broker/src/main/java/org/apache/pinot/broker/broker/helix/BaseBrokerStarter.java:
##########
@@ -129,6 +131,12 @@ public abstract class BaseBrokerStarter implements
ServiceStartable {
private volatile boolean _isStarting = false;
private volatile boolean _isShuttingDown = false;
+ // Class dedicated towards handling cluster config change
+ protected final DefaultClusterConfigChangeHandler
_defaultClusterConfigChangeHandler =
+ new DefaultClusterConfigChangeHandler();
+
+ // Deprecated in favor of using a dedicated
_defaultClusterConfigChangeHandler to manage config related changes
+ @Deprecated
Review Comment:
but doesn't `BaseBrokerStarter._clusterConfigChangeHandlers` use the
`ClusterChangeHandler`. why are we making a call that this is not the preferred
way for the handling cluster config changes? that's my question - we should
eventually consolidate the two mechanisms, rather than marking this list as
deprecated. and like I mentioned they are both meant to update the configs but
do it in different ways with additional capabilities in the older way.
I don't think that we should expect folks to stop using the
`ClusterChangeHandler` way of handling the changes for all cluster configs
going forward. that may be more desirable for some use cases especially for
where's it's used on the Broker side today (or at least i haven't done the
analysis for whether the additional functionality is necessary or not).
Perhaps you can instead integrate your Audit code to use the existing
mechanism and use `ClusterChangeHandler` if you want to have a single way to do
this on the Broker side?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
