rabashizade commented on code in PR #2106:
URL: https://github.com/apache/helix/pull/2106#discussion_r881988207
##########
helix-core/src/main/java/org/apache/helix/controller/dataproviders/BaseControllerDataProvider.java:
##########
@@ -241,13 +244,87 @@ private void refreshClusterConfig(final HelixDataAccessor
accessor,
if
(_propertyDataChangedMap.get(HelixConstants.ChangeType.CLUSTER_CONFIG).getAndSet(false))
{
_clusterConfig =
accessor.getProperty(accessor.keyBuilder().clusterConfig());
refreshedType.add(HelixConstants.ChangeType.CLUSTER_CONFIG);
+ // TODO: This is a temp function to clean up incompatible batched
disabled instances format.
+ // Remove in later version.
+ if (checkBatchedDisabledInstanceFormat(_clusterConfig) &&
updateBatchDisableFormat(
+ accessor)) {
+ // read from zkz one more time
+ LogUtil.logInfo(logger, getClusterEventId(), String
+ .format("Clean ClusterConfig change for cluster %s, pipeline %s",
_clusterName,
+ getPipelineName()));
+ _clusterConfig =
accessor.getProperty(accessor.keyBuilder().clusterConfig());
Review Comment:
In general, I agree that cache and ZK must have the same view. However, in
this case what's the risk of updating cache ahead of ZK? It's not new
information, but just fixing formatting. The same fix to ZK will be attempted
the next time the pipeline is running. But even if we want to avoid version
mismatch, the success of ZK update can be checked and then instead of reading
from ZK again, the same changes can be applied to `_clusterConfig`.
--
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]
