jiajunwang commented on a change in pull request #690: Reset the WAGED
rebalancer once the controller newly acquires leadership.
URL: https://github.com/apache/helix/pull/690#discussion_r371469494
##########
File path:
helix-core/src/main/java/org/apache/helix/controller/GenericHelixController.java
##########
@@ -1258,4 +1293,57 @@ private void initPipeline(Thread eventThread,
BaseControllerDataProvider cache)
eventThread.setDaemon(true);
eventThread.start();
}
+
+ /**
+ * A wrapper class for the stateful rebalancer instance that will be tracked
in the
+ * GenericHelixController.
+ */
+ private abstract class StatefulRebalancerRef<T extends StatefulRebalancer> {
+ private T _rebalancer = null;
+ private boolean _isRebalancerValid = true;
+
+ /**
+ * @param helixManager
+ * @return A new stateful rebalancer instance with initial state.
+ */
+ protected abstract T createRebalancer(HelixManager helixManager);
+
+ /**
+ * Mark the current rebalancer object to be invalid, which indicates it
needs to be reset before
+ * the next usage.
+ */
+ synchronized void invalidateRebalancer() {
+ _isRebalancerValid = false;
+ }
+
+ /**
+ * @return A valid rebalancer object.
+ * If the rebalancer is no longer valid, it will be reset before
returning.
+ */
+ synchronized T getRebalancer(HelixManager helixManager) {
+ // Lazily initialize the stateful rebalancer instance since the
GenericHelixController
+ // instance is instantiated without the HelixManager information that is
required.
+ if (_rebalancer == null) {
+ _rebalancer = createRebalancer(helixManager);
+ _isRebalancerValid = true;
+ }
+ // If the rebalance exists but has been marked as invalid (due to
leadership switch), it needs
+ // to be reset before return.
+ if (!_isRebalancerValid) {
+ _rebalancer.reset();
+ _isRebalancerValid = true;
+ }
+ return _rebalancer;
Review comment:
I still think it is not necessary since we want to maximize the event
handling performance here.
1. getRebalancer is called in a single thread, there is no concern that
multiple getRebalancer will cause the rebalancer to be created multiple times.
2. the possible concern is between getRebalancer() and closeRebalancer().
2.1. it is not possible that getRebalancer is called after closeRebalancer.
Since the event thread has been stopped by the controller before
closeRebalancer is triggered.
2.2. if the closeRebalancer is called after getRebalancer, and the reference
has not been safed in the main memory, closeRebalancer does nothing. The clean
up will be done a little bit late while the rebalancer object is GCed. This is
fine. Since the controller has been close, the rebalancer will not be used for
sure.
3. On the other hand, when adding volatile to the _rebalancer object, each
getRebalancer will access the main memory. It's a minor delay increament, but
if it happens on every event, these latencies together might count something.
So I prefer not adding volatile unless it help to resolve a real concern.
Moreover, as I mentioned, the rebalancer should not be a singleton by design.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
