-
Notifications
You must be signed in to change notification settings - Fork 594
HDDS-5202. Use scm#checkLeader before processing client requests . #2229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -145,7 +145,7 @@ public StorageContainerLocationProtocolServerSideTranslatorPB( | |
| public ScmContainerLocationResponse submitRequest(RpcController controller, | ||
| ScmContainerLocationRequest request) throws ServiceException { | ||
| // not leader or not belong to admin command. | ||
| if (!scm.getScmContext().isLeader() | ||
| if (!scm.checkLeader() | ||
|
||
| && !ADMIN_COMMAND_TYPE.contains(request.getCmdType())) { | ||
| RatisUtil.checkRatisException( | ||
| scm.getScmHAManager().getRatisServer().triggerNotLeaderException(), | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we separate NotLeaderException and LeaderNotReadyException ? client should failover for the former one, and retry the same SCM for the latter one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know whether ratis now has the feature of leader-lease, with which scm will not need to check this every time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not implemented yet, tracked by https://issues.apache.org/jira/browse/RATIS-1273
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason behind adding this check is that read requests should not be processed before becoming leader becomes ready.
The reason is We do not want to serve the reads based on not up-to-date SCM DB. For writes as this is going via ratis, this is already taken care.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea, let me update based on that.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GlenGeng As we have suggested Leader handling in Client, even though it throws error NotLeader Exception to the client, but it passes the leaderAddress in the case of LeaderNotReady it will be the same node address so retry will happen on the same Node. So, I believe we are good here. (We can keep simple as we have suggested leader handling in SCM)