ZOOKEEPER-4220: Potential redundant connection attempts during leader election - branch-3.5 #1631
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… election We have a logic in the server code, that would try to connect to an other quorum member, based on its server ID. We identify the address assigned to this ID first based on the last committed quorum configuration. If the connection attempt fails (or the server is not known in the committed configuration) then we try to find the address based on the last proposed quorum configuration. But we should do the second connection attempt, only if the address in the last proposed configuration differs from the address in the last committed configuration. Otherwise we would just retry to connect to the same address that failed just right before. In the current code we have a bug, because we compare the address object references (use "!=") instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g. when the last proposed and last committed addresses are the same, but the address is unreachable) this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to mark this connection attempt to be failed and wait for e.g. the next election round or wait for the other server to come online and initiate a connection to us. Author: Mate Szalay-Beko <[email protected]> Reviewers: Andor Molnar <[email protected]>, Damien Diederen <[email protected]> Closes apache#1615 from symat/ZOOKEEPER-4220
|
created this PR to kick-in CI on branch 3.5 for #1615 |
asfgit
pushed a commit
that referenced
this pull request
Mar 9, 2021
… election We have a logic in the server code, that would try to connect to an other quorum member, based on its server ID. We identify the address assigned to this ID first based on the last committed quorum configuration. If the connection attempt fails (or the server is not known in the committed configuration) then we try to find the address based on the last proposed quorum configuration. But we should do the second connection attempt, only if the address in the last proposed configuration differs from the address in the last committed configuration. Otherwise we would just retry to connect to the same address that failed just right before. In the current code we have a bug, because we compare the address object references (use "!=") instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g. when the last proposed and last committed addresses are the same, but the address is unreachable) this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to mark this connection attempt to be failed and wait for e.g. the next election round or wait for the other server to come online and initiate a connection to us. Author: Mate Szalay-Beko <[email protected]> Reviewers: Andor Molnar <[email protected]>, Damien Diederen <[email protected]> Closes #1631 from symat/ZOOKEEPER-4220-branch-3.5
|
Thank you for taking care of it, @symat! |
anmolnar
pushed a commit
to anmolnar/zookeeper
that referenced
this pull request
May 21, 2024
… election We have a logic in the server code, that would try to connect to an other quorum member, based on its server ID. We identify the address assigned to this ID first based on the last committed quorum configuration. If the connection attempt fails (or the server is not known in the committed configuration) then we try to find the address based on the last proposed quorum configuration. But we should do the second connection attempt, only if the address in the last proposed configuration differs from the address in the last committed configuration. Otherwise we would just retry to connect to the same address that failed just right before. In the current code we have a bug, because we compare the address object references (use "!=") instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g. when the last proposed and last committed addresses are the same, but the address is unreachable) this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to mark this connection attempt to be failed and wait for e.g. the next election round or wait for the other server to come online and initiate a connection to us. Author: Mate Szalay-Beko <[email protected]> Reviewers: Andor Molnar <[email protected]>, Damien Diederen <[email protected]> Closes apache#1631 from symat/ZOOKEEPER-4220-branch-3.5 (cherry picked from commit 755cb27) Change-Id: Ia1eddfb5edb8cc3f791d010301dbc1f9e2c682f5
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have a logic in the server code, that would try to connect to an other quorum member, based
on its server ID. We identify the address assigned to this ID first based on the last committed
quorum configuration. If the connection attempt fails (or the server is not known in the
committed configuration) then we try to find the address based on the last proposed quorum
configuration. But we should do the second connection attempt, only if the address in the
last proposed configuration differs from the address in the last committed configuration.
Otherwise we would just retry to connect to the same address that failed just right before.
In the current code we have a bug, because we compare the address object references (use "!=")
instead of comparing the objects themselves (using "not equals"). In certain edge cases (e.g.
when the last proposed and last committed addresses are the same, but the address is unreachable)
this bug can lead to unnecessary retry of connection attempts. The normal behaviour would be to
mark this connection attempt to be failed and wait for e.g. the next election round or wait for
the other server to come online and initiate a connection to us.