You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not an Aleph issue specifically... more like a flaw of async event-driven HTTP communication. Unfortunately with practical implications.
Let's assume I'm using HTTP client and
The server responds with the body that exceeds :response-buffer-size
I do not use :body of the response at all (e.g. I just read headers) or failed to read the entire body.
By default read-timeout is not set, so the client will wait until the body consumption is complete "always" (unless server closes the connection, but we cannot rely on that fact at all). Effectively blocking an acquired connection from the pool. Which eventually would lead to the pool being exhausted and application being "stuck".
In the ideal world, we need to ensure that after response processing is done at least on the requirements is met: either :body is fully consumed or underlying connection is closed. As we cannot do the first, I think it makes sense at least to introduce an API to have an option to close connection explicitly manually.
The text was updated successfully, but these errors were encountered:
Depending on whether :raw-stream? is true, both the Manifold stream and InputStream have "close" methods that can be used to discard the underlying connection. We could create a method that encompasses both, but I'm not sure that offers much value. In either case, I agree this should be explicitly documented.
It's not an Aleph issue specifically... more like a flaw of async event-driven HTTP communication. Unfortunately with practical implications.
Let's assume I'm using HTTP client and
The server responds with the body that exceeds
:response-buffer-size
I do not use
:body
of the response at all (e.g. I just read headers) or failed to read the entire body.By default
read-timeout
is not set, so the client will wait until the body consumption is complete "always" (unless server closes the connection, but we cannot rely on that fact at all). Effectively blocking an acquired connection from the pool. Which eventually would lead to the pool being exhausted and application being "stuck".In the ideal world, we need to ensure that after response processing is done at least on the requirements is met: either
:body
is fully consumed or underlying connection is closed. As we cannot do the first, I think it makes sense at least to introduce an API to have an option to close connection explicitly manually.The text was updated successfully, but these errors were encountered: