-
Notifications
You must be signed in to change notification settings - Fork 24.5k
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
Circuit-break on response size #42318
Comments
Pinging @elastic/es-core-infra |
\cc @ywelsch @DaveCTurner |
The es-core-infra team discussed and we believe that this is something worth implementing as a way to add additional safeguards. |
@elastic/es-core-infra Any updates or workarounds available? |
@felix-lessoer This is not actively being worked on at this time. It’s on our list, but we are addressing more important priorities currently. |
I added the The above issue was also mentioned from the https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html page where we stated the STATUS is still ongoing:
|
Are contributors welcome to look into this? |
This has become unnecessary with the introduction of chunked rest responses which turn the amount of memory needed for serialising the mentioned responses O(1). Once we're through converting all APIs that might result in a large response to chunked encoding there's no need for a circuit breaker. |
We have a circuit breaker for in_flight request but we don't check the response size even for APIs that can return big json output. For instance getting all
_segments
in a big cluster with lot of indices can kill the node responsible for the request since it needs to gather a lot of internal response as well as the final response that needs to be serialized in json. It could be beneficial to add a circuit breaker that checks the size of the transport responses when executing internal requests through the transport layer and to also control the memory usage of the response that is serialized at the rest layer. The latter is more important due to the json serialization that can be very verbose.The text was updated successfully, but these errors were encountered: