Release limiters when response is returned #1255
Conversation
Generate changelog in
|
| @@ -52,7 +46,7 @@ | |||
| * 429 and 503 response codes are used for backpressure, whilst 200 -> 399 request codes are used for determining | |||
| * new limits and all other codes are not factored in to timings. | |||
| * <p> | |||
| * Concurrency permits are only released when the response body is closed. | |||
| * Concurrency permits are released when the response is received. | |||
There was a problem hiding this comment.
I think this was discussed in the past and in general would be kinda against the principle of concurrency limiting: the fact that the body is being streamed usually means that the worker thread might have been released, but streaming the body still usually consumes resources (especially if it's just a blocking read that goes from some external resource and writes to the response body).
I think the reason why you are not observing any 429 in general in that situation is that the internal product that I expect you're referring too has request/sec rate limiting implemented, not concurrency limiting. I suspect releasing more of requests here would eventually lead to 503s from the product.
|
This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days. |
|
On your original issue (this is artifacts right?) doesn't c-j-r's limit still increase, so this should only affect a cold startup? |
|
This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days. |
fixes #1192
Before this PR
Concurrency permits are only released when the response body is closed.
After this PR
==COMMIT_MSG==
Concurrency permits are now released when the response is received.
==COMMIT_MSG==
Possible downsides?