Skip to content

Conversation

@symious
Copy link
Contributor

@symious symious commented May 13, 2022

What changes were proposed in this pull request?

Currently if clients first connect to a follower OM, the response show the OM is not leader but didn't specify the real Leader node.

This ticket is to let the reply to contains the Leader OM so that clients can connect to Leader node more conveniently.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-6743

How was this patch tested?

unit test

@symious
Copy link
Contributor Author

symious commented May 13, 2022

@adoroszlai @ChenSammi Could you help to review this PR?

@JacksonYao287
Copy link
Contributor

thanks @symious for the work!
i have a patch for this issue earlier #2765

@hanishakoneru left a comment to explain why this should not be done. #2765 (comment)

i suggest we should achieve agreement on this issue first , and then go ahead.

@symious
Copy link
Contributor Author

symious commented May 13, 2022

@JacksonYao287 Sure, thanks for the review.

In #2765 (comment), the concern I think is the misconfig of client side might trigger some dead loops, so an address was prefered to add instead of only OMNodeId.

In the latest commit of this PR, the OMNotLeaderException includes the following information:

  1. raftPeerId
  2. raftLeaderId
  3. raftLeaderAddress

An example of this exception message would be
org.apache.hadoop.ozone.om.exceptions.OMNotLeaderException: OM:omNode-3 is not the leader. Suggested leader is OM:omNode-1/127.0.0.1
, when client received this exception, he should try the address first, only if the address is empty should he try to check the raftLeaderId we suggested.

@kerneltime
Copy link
Contributor

@symious is this PR still active? If not we can close it.

@DaveTeng0
Copy link
Contributor

Just saw this PR, recently I've also been researching some issue related to the out-of-sync mapping between client and server. just mark myself here in order to follow up the latest change of this PR! thanks all!

@symious
Copy link
Contributor Author

symious commented Nov 1, 2022

@kerneltime Still active I think, could you help to review the PR?
I will resolve the conflictions later.

@kerneltime
Copy link
Contributor

thanks @symious will get this reviewed

@kerneltime
Copy link
Contributor

@kerneltime kerneltime requested review from ChenSammi, kerneltime and neils-dev and removed request for hanishakoneru November 4, 2022 08:02
@DaveTeng0
Copy link
Contributor

Changes look good to me!
(hope this could be merged, I definitely could utilize them in one of my current task! thanks!)

this.leaderAddress = suggestedLeaderAddress;
}

public OMNotLeaderException(String message) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should not support this. The caller has to specify either the peer ID or the leader ID.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@kerneltime
Copy link
Contributor

The overall change looks good and would help debug as well. Some minor nits that need addressing.

@swamirishi
Copy link
Contributor

@kerneltime The review comments have been addressed. I guess this can be merged.

@kerneltime
Copy link
Contributor

@swamirishi thanks for the update. I will take a look.
@neils-dev can you please revisit the PR as well?

@symious
Copy link
Contributor Author

symious commented Feb 7, 2023

@neils-dev Updated the PR, please have a look.

@neils-dev
Copy link
Contributor

Thanks @symious . I tested failover on the docker ha dev cluster and noticed that when leader node goes down, the followers respond in one of two ways, either i.) initially providing a stale om leader or ii,) null address om suggestion.

i.) (stale leader suggestion) ozone-ha-om2-1 | 2023-02-14 01:22:51 DEBUG OzoneManagerProtocolServerSideTranslatorPB:251 - OM:om2 is not the leader. Suggested leader is OM:om3[om3/172.27.0.9].

ii.) ozone-ha-om2-1 | 2023-02-14 01:24:07 DEBUG OzoneManagerProtocolServerSideTranslatorPB:251 - OM:om2 is not the leader. Suggested leader is OM:om3[null].

The null address in the suggestion seems to be effective causing the failover provider to choose the next om to try from its om node map and resolves the failover.

Q. should the node give a stale om leader id, is it possible that we encounter a loop condition where we continue to try the suggestion, fail, then ask the same om for the suggestion that we already tried?
https://github.com/symious/ozone/blob/98caa74e8870829f974e77b89da6d293b7db62cd/hadoop-ozone/common/src/main/java/org/apache/hadoop/ozone/om/ha/OMFailoverProxyProviderBase.java#L189

@symious
Copy link
Contributor Author

symious commented Feb 14, 2023

@neils-dev Thank you for the review. Updated the patch, could you have a check?

I think the problem you mentioned happens when the leader is not generated, once the leader is confirmed, the client should be forwarded to the correct OM.

Copy link
Contributor

@neils-dev neils-dev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @symious for the updates. LGTM.
@kerneltime do you mind taking a look? If no further comments we should look to merge.

@neils-dev
Copy link
Contributor

Thanks @JacksonYao287 , @kerneltime , @DaveTeng0 , @swamirishi for your review and comments. Thanks @symious for this. Merge to master.

@neils-dev neils-dev merged commit c9bbb03 into apache:master Feb 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants