Skip to content
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

ZOOKEEPER-4220: Potential redundant connection attempts during leader election #112

Merged
merged 1 commit into from
Nov 2, 2022

Conversation

anuragmadnawat1
Copy link
Owner

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

… 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
@anuragmadnawat1 anuragmadnawat1 merged commit 2f2d3e6 into master Nov 2, 2022
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.

2 participants