-
Notifications
You must be signed in to change notification settings - Fork 9.1k
HADOOP-18345: Enhance client protocol to propagate last seen state IDs for multiple nameservices. #4584
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
HADOOP-18345: Enhance client protocol to propagate last seen state IDs for multiple nameservices. #4584
Conversation
@ZanderXu do you mind taking a look. |
💔 -1 overall
This message was automatically generated. |
@@ -157,6 +158,7 @@ message RpcResponseHeaderProto { | |||
optional bytes clientId = 7; // Globally unique client ID | |||
optional sint32 retryCount = 8 [default = -1]; | |||
optional int64 stateId = 9; // The last written Global State ID | |||
map<string, int64> nameserviceStateIds = 10; // Last seen state IDs for multiple nameservices. |
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.
Can we add some unit tests?
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.
@goiri The classes that will interact with these header fields will be in the hadoop-hdfs-client module, so it is hard to then keep changes and tests contained within hadoop-common. I don't have a workaround at the moment but I'll keep trying to think of alternative ways to test. Let me know if you have any ideas with regards to this.
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.
Doesn't this field need to be optional
for backwards compatibility?
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.
Yes, it should be optional. Thanks for spotting the error. I'll fix that.
I'm also going to make this a bytearray since the client doesn't need to parse it. This will give us the flexibility to evolve the contents in the routers.
@simbadzina About "RBF supports Observer Read", it's a hug and helpful project. We'd better discuss the overall implementation plan first, and then start development and code review after reaching an agreement, how? |
@ZanderXu please take a look at: |
Copy, sir. I will follow up this feature and push it forward with @simbadzina together. |
Yes, it should be optional. Thanks for spotting the error. I'll fix that.
I'm considering making the field a byte array in the client protocol. Only
routers need to parse it.
…On Mon, Jul 25, 2022, 16:51 Erik Krogen ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In hadoop-common-project/hadoop-common/src/main/proto/RpcHeader.proto
<#4584 (comment)>:
> @@ -157,6 +158,7 @@ message RpcResponseHeaderProto {
optional bytes clientId = 7; // Globally unique client ID
optional sint32 retryCount = 8 [default = -1];
optional int64 stateId = 9; // The last written Global State ID
+ map<string, int64> nameserviceStateIds = 10; // Last seen state IDs for multiple nameservices.
Doesn't this field need to be optional for backwards compatibility?
—
Reply to this email directly, view it on GitHub
<#4584 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC6NI6DC23A4WNI4AARIIW3VV4SBNANCNFSM53457PHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
92a3e9a
to
ebf23a3
Compare
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
ebf23a3
to
ecca8e6
Compare
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
981e17c
to
efd4e35
Compare
🎊 +1 overall
This message was automatically generated. |
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.
This is looking good. Just a few minor factoring changes.
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/ipc/RpcConstants.java
Outdated
Show resolved
Hide resolved
hadoop-common-project/hadoop-common/src/main/proto/RpcHeader.proto
Outdated
Show resolved
Hide resolved
hadoop-common-project/hadoop-common/src/main/proto/RpcHeader.proto
Outdated
Show resolved
Hide resolved
🎊 +1 overall
This message was automatically generated. |
2a76bb5
to
ccdb70c
Compare
🎊 +1 overall
This message was automatically generated. |
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.
+1 LGTM
@omalley I'm guessing the close was accidental? |
…for multiple nameservices. Fixes #4584 Signed-off-by: Owen O'Malley <oomalley@linkedin.com>
@goiri No, I committed the change to trunk and branch-3.3. Was there still an open issue on this PR? |
No worries, you merged manually instead of merging the existing PR. |
…for multiple nameservices. Fixes apache#4584 Signed-off-by: Owen O'Malley <oomalley@linkedin.com>
…for multiple nameservices. Fixes apache#4584 Signed-off-by: Owen O'Malley <oomalley@linkedin.com>
…for multiple nameservices. Fixes apache#4584 Signed-off-by: Owen O'Malley <oomalley@linkedin.com> (cherrypicked from e28dc52) RB=3579342 BUG=LIHADOOP-66568 G=storage-reviewers R=yzhang12,oomalley,hchaverr A=hchaverr
…for multiple nameservices. Fixes apache#4584 Signed-off-by: Owen O'Malley <oomalley@linkedin.com>
Description of PR
Enhance client protocol to propagate last seen state IDs for multiple nameservices.
How was this patch tested?
This is a prerequisite for HDFS-13522. There are tests in the that JIRA.
For code changes: