KAFKA-15817: Avoid reconnecting to the same IP address if multiple ad…#14813
Merged
lucasbru merged 1 commit intoapache:trunkfrom Nov 27, 2023
Merged
KAFKA-15817: Avoid reconnecting to the same IP address if multiple ad…#14813lucasbru merged 1 commit intoapache:trunkfrom
lucasbru merged 1 commit intoapache:trunkfrom
Conversation
…dresses are available
Member
|
Thanks for the PR. Let's cherry pick this to 3.6 after this is merged to master. |
Member
|
test failures are know flaky tests |
Member
|
@lucasbru Did you cherry-pick to 3.6? |
Member
|
@ijuma I did not. My understanding was that this shouldn't be included in 3.6.1, so I was waiting for 3.6.1 to go through before cherry-picking it. |
cadonna
pushed a commit
to cadonna/kafka
that referenced
this pull request
Dec 11, 2023
If multiple addresses are available. This change is a follow-up to apache#9902. When re-resolving DNS after disconnecting, it is possible (likely, even) that we will resolve the same set of addresses in the same order, meaning we could attempt to reconnect to the same IP that we just disconnected from. In the case where we disconnected from the IP address because it has become unhealthy (due to a load balancer going down or a network routing layer restarting, for example), the client will need to time out before connecting to the next IP. This essentially unifies the behavior before and after KAFKA-12193: re-resolve after disconnecting while still progressing through the IP list. Reviewers: Lucas Brutschy <[email protected]>, Andrew Schofield <[email protected]>
cadonna
added a commit
that referenced
this pull request
Jan 4, 2024
If multiple addresses are available. This change is a follow-up to #9902. When re-resolving DNS after disconnecting, it is possible (likely, even) that we will resolve the same set of addresses in the same order, meaning we could attempt to reconnect to the same IP that we just disconnected from. In the case where we disconnected from the IP address because it has become unhealthy (due to a load balancer going down or a network routing layer restarting, for example), the client will need to time out before connecting to the next IP. This essentially unifies the behavior before and after KAFKA-12193: re-resolve after disconnecting while still progressing through the IP list. Cherry-pick of 47e3777 Reviewers: Lucas Brutschy <[email protected]>, Andrew Schofield <[email protected]> Co-authored-by: Bob Barrett <[email protected]>
yyu1993
pushed a commit
to yyu1993/kafka
that referenced
this pull request
Feb 15, 2024
If multiple addresses are available. This change is a follow-up to apache#9902. When re-resolving DNS after disconnecting, it is possible (likely, even) that we will resolve the same set of addresses in the same order, meaning we could attempt to reconnect to the same IP that we just disconnected from. In the case where we disconnected from the IP address because it has become unhealthy (due to a load balancer going down or a network routing layer restarting, for example), the client will need to time out before connecting to the next IP. This essentially unifies the behavior before and after KAFKA-12193: re-resolve after disconnecting while still progressing through the IP list. Reviewers: Lucas Brutschy <[email protected]>, Andrew Schofield <[email protected]>
clolov
pushed a commit
to clolov/kafka
that referenced
this pull request
Apr 5, 2024
If multiple addresses are available. This change is a follow-up to apache#9902. When re-resolving DNS after disconnecting, it is possible (likely, even) that we will resolve the same set of addresses in the same order, meaning we could attempt to reconnect to the same IP that we just disconnected from. In the case where we disconnected from the IP address because it has become unhealthy (due to a load balancer going down or a network routing layer restarting, for example), the client will need to time out before connecting to the next IP. This essentially unifies the behavior before and after KAFKA-12193: re-resolve after disconnecting while still progressing through the IP list. Reviewers: Lucas Brutschy <[email protected]>, Andrew Schofield <[email protected]>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
…dresses are available
This change is a follow-up to #9902. When re-resolving DNS after disconnecting, it is possible (likely, even) that we will resolve the same set of addresses in the same order, meaning we could attempt to reconnect to the same IP that we just disconnected from. In the case where we disconnected from the IP address because it has become unhealthy (due to a load balancer going down or a network routing layer restarting, for example), the client will need to time out before connecting to the next IP. This essentially unifies the behavior before and after KAFKA-12193: re-resolve after disconnecting while still progressing through the IP list.
Committer Checklist (excluded from commit message)