hanishakoneru commented on a change in pull request #3160:
URL: https://github.com/apache/ozone/pull/3160#discussion_r823203520
##########
File path:
hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/ha/OMFailoverProxyProvider.java
##########
@@ -261,9 +263,9 @@ public RetryAction shouldRetry(Exception exception, int
retries,
// address of the suggested leader along with the nodeID.
// Failing over just based on nodeID is not very robust.
- // OMFailoverProxyProvider#performFailover() is a dummy call and
- // does not perform any failover. Failover manually to the next OM.
- performFailoverToNextProxy();
+ // Prepare the next OM to be tried. This will help with calculation
+ // of the wait times needed get creating the retryAction.
+ selectNextOmProxy();
Review comment:
Agree.
Even though performFailover will be called only once by concurrent failed
invocations (guaranteed by RetryInvocationHandler), this code does not
guarantee that the failover will occur to the next proxy. The failover could as
well happen to the same proxy if we do not ensure that selectNextOmProxy is
effective only once for concurrent failovers (same as before).
Having nextOmProxyId == currentOmProxyId check would help here.
The reason for not using the RetryInvocationHandler#performFailover() to do
the actual failover was that with the base method we could not failover to the
suggested leader OM (which we are anyway not doing currently but it would be
good to add it back).
Would it be better to update the suggested leaderOM from shouldRetry and
make the decision to failover to the suggested LeaderOM or the next proxy from
performFailover? It would reduce the complexity of using synchronized methods
in OmFailoverProxyProvider. The attemptedOMs list (used to calculate waitTime)
can also be updated from performFailover. Have to think about the implications
for this once again.
--
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]
