Skip cluster state serialization to closed channel #67413
Merged
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
Today if a client requests a cluster state and then closes the connection then we still do all the work of computing and serializing the cluster state before finally dropping it all on the floor. With this commit we introduce checks to make sure that the HTTP channel is still open before starting the serialization process. We also make the tasks themselves cancellable and abort any ongoing waiting if the channel is closed (mainly to make the cancellability testing easier). Finally we introduce a more detailed description of the task to help identify cases where clients are inefficiently requesting more components of the cluster state than they need.
DaveCTurner
added
>enhancement
:Distributed Coordination/Cluster Coordination
elasticmachine
added
the
Team:Distributed (Obsolete)
Collaborator
|
Pinging @elastic/es-distributed (Team:Distributed) |
Contributor
original-brownbear
left a comment
original-brownbear
left a comment
There was a problem hiding this comment.
One question, will give the test another read otherwise but otherwise looks nice :)
| singletonMap(Metadata.CONTEXT_MODE_PARAM, Metadata.CONTEXT_MODE_API), request); | ||
| response.getState().toXContent(builder, params); | ||
| final ClusterState responseState = response.getState(); | ||
| if (responseState != null) { |
Contributor
There was a problem hiding this comment.
Only question pretty much on this one: why can this be null all of a sudden?
Contributor
Author
There was a problem hiding this comment.
It was always thus:
TBF this only happens if it times out waiting for a particular metadata version, which in practice means the client is CCR and therefore not going via the REST layer anyway.
DaveCTurner
added a commit
that referenced
this pull request
Jan 13, 2021
Today if a client requests a cluster state and then closes the connection then we still do all the work of computing and serializing the cluster state before finally dropping it all on the floor. With this commit we introduce checks to make sure that the HTTP channel is still open before starting the serialization process. We also make the tasks themselves cancellable and abort any ongoing waiting if the channel is closed (mainly to make the cancellability testing easier). Finally we introduce a more detailed description of the task to help identify cases where clients are inefficiently requesting more components of the cluster state than they need.
DaveCTurner
added a commit
that referenced
this pull request
Jan 13, 2021
This reverts commit 563d07f.
DaveCTurner
added a commit
to DaveCTurner/elasticsearch
that referenced
this pull request
Jan 13, 2021
Today if a client requests a cluster state and then closes the connection then we still do all the work of computing and serializing the cluster state before finally dropping it all on the floor. With this commit we introduce checks to make sure that the HTTP channel is still open before starting the serialization process. We also make the tasks themselves cancellable and abort any ongoing waiting if the channel is closed (mainly to make the cancellability testing easier). Finally we introduce a more detailed description of the task to help identify cases where clients are inefficiently requesting more components of the cluster state than they need. Backport of elastic#67413
DaveCTurner
added a commit
that referenced
this pull request
Jan 13, 2021
Today if a client requests a cluster state and then closes the connection then we still do all the work of computing and serializing the cluster state before finally dropping it all on the floor. With this commit we introduce checks to make sure that the HTTP channel is still open before starting the serialization process. We also make the tasks themselves cancellable and abort any ongoing waiting if the channel is closed (mainly to make the cancellability testing easier). Finally we introduce a more detailed description of the task to help identify cases where clients are inefficiently requesting more components of the cluster state than they need. Backport of #67413
DaveCTurner
added a commit
to DaveCTurner/elasticsearch
that referenced
this pull request
Feb 16, 2021
A small followup to elastic#67413 and elastic#68965: the underlying actions of the `GET /_cat/segments` API are now cancellable, so we may as well cancel them if needed.
DaveCTurner
added a commit
that referenced
this pull request
Feb 16, 2021
DaveCTurner
added a commit
that referenced
this pull request
Feb 16, 2021
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.
Today if a client requests a cluster state and then closes the
connection then we still do all the work of computing and serializing
the cluster state before finally dropping it all on the floor.
With this commit we introduce checks to make sure that the HTTP channel
is still open before starting the serialization process. We also make
the tasks themselves cancellable and abort any ongoing waiting if the
channel is closed (mainly to make the cancellability testing easier).
Finally we introduce a more detailed description of the task to help
identify cases where clients are inefficiently requesting more
components of the cluster state than they need.