MarkGaox commented on code in PR #2595:
URL: https://github.com/apache/helix/pull/2595#discussion_r1294938531
##########
helix-core/src/main/java/org/apache/helix/model/ClusterConfig.java:
##########
@@ -151,7 +151,10 @@ public enum ClusterConfigProperty {
HELIX_ENABLED_DISABLE_TIMESTAMP,
HELIX_DISABLED_REASON,
// disabled type should be a enum of
org.apache.helix.constants.InstanceConstants.InstanceDisabledType
- HELIX_DISABLED_TYPE
+ HELIX_DISABLED_TYPE,
+
+ // The last time when the on-demand rebalance is triggered.
+ LAST_ON_DEMAND_REBALANCE_TIMESTAMP
Review Comment:
When there are two calls C1 and C2 and C1 < C2, it's true that C1 will be
overwritten by C2. It's fine for the rebalance triggered by C1 to be based on
C2 timestamp because it won't make any difference. All offline/disabled nodes
are still going to be rebalanced as long as T1 < C2 && C2 < T3. As for the
rebalance call of C2, when it takes place the cluster is already rebalanced,
therefore making no changes. Generally, we don't expect users to make
concurrent cluster management API calls (but I understand it's not a good idea
to make such assumption hahaha....). Hope this explains your concern.
For now, we only trigger the cluster level rebalance. We won't implement the
fine-grained control of selecting which set of servers to be rebalanced unless
the user explicitly requests that.
--
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]
