-
Notifications
You must be signed in to change notification settings - Fork 588
HDDS-11901. use om managed index for handling request #7722
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
Conversation
d814294 to
a12079f
Compare
|
Sorry for cancelling the workflow. I will resolve conflicts after HDDS-12277 and trigger CI. |
...one/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/execution/common/BiConsumerX.java
Outdated
Show resolved
Hide resolved
adoroszlai
left a comment
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.
Thanks @sumitagrawl for the patch.
...p-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/execution/IndexGenerator.java
Outdated
Show resolved
Hide resolved
...p-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/execution/IndexGenerator.java
Outdated
Show resolved
Hide resolved
...p-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/execution/IndexGenerator.java
Show resolved
Hide resolved
...e/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/ratis/OzoneManagerDoubleBuffer.java
Outdated
Show resolved
Hide resolved
...one/ozone-manager/src/test/java/org/apache/hadoop/ozone/om/execution/TestIndexGenerator.java
Outdated
Show resolved
Hide resolved
...p-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/execution/IndexGenerator.java
Outdated
Show resolved
Hide resolved
7439a51 to
0d3a31d
Compare
|
@adoroszlai resolved all comments and fixed license header changes, please review again |
I have already fixed license headers, see: |
|
Thanks @sumitagrawl for addressing my comments. I'll let others review as well. |
| } | ||
| index.set(initIndex); | ||
| commitIndex.set(initIndex); | ||
| if (ozoneManager.getVersionManager().needsFinalization()) { |
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 check whether this specific feature needs finalization, instead of a general needsFinalization check, as needsFinalization will return true once there is new feature added and not finalized.
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.
updated
...manager/src/main/java/org/apache/hadoop/ozone/om/execution/flowcontrol/ExecutionContext.java
Outdated
Show resolved
Hide resolved
...manager/src/main/java/org/apache/hadoop/ozone/om/execution/flowcontrol/ExecutionContext.java
Show resolved
Hide resolved
...p-ozone/ozone-manager/src/main/java/org/apache/hadoop/ozone/om/execution/IndexGenerator.java
Show resolved
Hide resolved
| LOG.info("{}: leader changed to {}", groupMemberId, newLeaderId); | ||
| // if the node is leader (can be ready or not ready, need update index) | ||
| if (ozoneManager.getOmRatisServer().checkLeaderStatus() != OzoneManagerRatisServer.RaftServerStatus.NOT_LEADER) { | ||
| indexGenerator.onLeaderChange(); |
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.
As every OM has its IndexGenerator, which works independently, could you explain a little bit here, what the onLeaderChange actually do?
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.
Since every OM has its IndexGenerator which works independently, could it be possible that for the same TermIndex transaction, its index has different value on different OM? If this happens, what will be the consequence?
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.
Ratis generate termIndex for below cases:
- transaction update via applyTransaction()
- notifyConfigChange for case of ratis internal book-keeping
IndexGenerate will generate index in pre-ratis execution for every incoming request at leader node.
So both can have different value, where mostly ratis index will be faster side.
OM will use OM index for purpose of objectId and updateId generation as used currently.
TermIndex will be used to handle replay of ratis log pending, and ensure nodes are in sync in upgrade prepare cases.
So use case will be separated and hence will not have impact.
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.
@ChenSammi I got the problem,
Since every node generate the index on request execution, so there is a possibility of different index value. All nodes should get index from common place in this case, will work over this to handle.
|
@ChenSammi updated the comments and code, plz review again |
Per we offline discussion, I suggest to start a feature branch for all these pre-ratis execution changes, as the idea of keeping both pre-ratis execution and current per-ratis execution work is really a ideal state. But mixing the code makes it complex, hard to understand clearly, and easy to go wrong on many edge cases, for example, this new Index should not the turned on until only the OM leader will call the IndexGenerator#nextIndex(). A feature branch will save the master from broken due to intermediate development state, cases not covered, bugs, etc. |
|
@ChenSammi Please review the changes done for fix
As change, ExecutionControlRequest parameter is added, and leader will append index generated before submit the request. This will resolve the above problem. |
|
Should this be targeted at the feature branch? |
What changes were proposed in this pull request?
Remove dependency with ratis index for OM functionality for request object. Introduced IndexManager that will keep track of OM index and provide next index for request execution.
#OMINDEXduring doubleBuffer commit operationOMLayout Feature flagfor handling upgrade and reinit on finalizeFlow:
ClientRequest: --> OmExecutionFlow --> generate index and add to Request ---> submit to ratis
Ratis: ApplyTransaction --> retrieve index and update ExecutionContext --> perform operation
Usages:
It will simplify applying om db from production environment to local for debug purpose, as ratis index impact will not cause failure to start.
Will be used for pre-ratis execution feature
Refer (HDDS-11898. design doc leader side execution) for
Index generationandStep-by-step incremental changes for existing flowParent Jira:
https://issues.apache.org/jira/browse/HDDS-11897
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-11900
How was this patch tested?