fix: do not let _resolve/cluster hang if remote is unresponsive
#119516
Conversation
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
Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination.
pawankartik-elastic
added
>bug
auto-backport
Collaborator
|
Pinging @elastic/es-search-foundations (Team:Search Foundations) |
Collaborator
|
Hi @pawankartik-elastic, I've created a changelog YAML for you. |
quux00
approved these changes
Jan 3, 2025
Contributor
quux00
left a comment
quux00
left a comment
There was a problem hiding this comment.
LGTM. Nice work researching this to have it culminate in being a one-liner!
This was referenced Jan 3, 2025
pawankartik-elastic
added a commit
to pawankartik-elastic/elasticsearch
that referenced
this pull request
Jan 3, 2025
…astic#119516) * fix: do not let `_resolve/cluster` hang if remote is unresponsive Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination. * Update docs/changelog/119516.yaml
pawankartik-elastic
added a commit
to pawankartik-elastic/elasticsearch
that referenced
this pull request
Jan 3, 2025
…astic#119516) * fix: do not let `_resolve/cluster` hang if remote is unresponsive Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination. * Update docs/changelog/119516.yaml
pawankartik-elastic
added a commit
to pawankartik-elastic/elasticsearch
that referenced
this pull request
Jan 3, 2025
…astic#119516) * fix: do not let `_resolve/cluster` hang if remote is unresponsive Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination. * Update docs/changelog/119516.yaml
Collaborator
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jan 3, 2025
…19516) (#119526) * fix: do not let `_resolve/cluster` hang if remote is unresponsive Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination. * Update docs/changelog/119516.yaml
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jan 3, 2025
…19516) (#119528) * fix: do not let `_resolve/cluster` hang if remote is unresponsive Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination. * Update docs/changelog/119516.yaml
elasticsearchmachine
pushed a commit
that referenced
this pull request
Jan 3, 2025
…19516) (#119527) * fix: do not let `_resolve/cluster` hang if remote is unresponsive Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination. * Update docs/changelog/119516.yaml
sarog
pushed a commit
to portsbuild/elasticsearch
that referenced
this pull request
Jan 22, 2025
…astic#119516) (elastic#119527) * fix: do not let `_resolve/cluster` hang if remote is unresponsive Previously, `_resolve/cluster` would wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait until `netty` would terminate the connection with a handshake exception. The threshold for terminating the connection is `10s`. This means that the API would wait for `10s` before determining that the remote is unresponsive. This strategy is now replaced with a fail fast where a response is sent back to the user immediately rather than waiting for a connection termination. * Update docs/changelog/119516.yaml
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Previously,
_resolve/clusterwould wait for a response from a remote as part of the connection strategy. If the remote were to be unresponsive, this API would wait untilnettywould terminate the connection with a handshake exception. The threshold for terminating the connection is10s. This means that the API would wait for10sbefore determining that the remote is unresponsive. After an internal discussion, this is now replaced with a fail fast strategy where a response is sent back to the user immediately rather than waiting for a connection termination.