On 14/03/2024 21:53, Jonathan Amir wrote:
Thanks for your answers, they help a lot. So far what I am understanding about the connection closed situation is that it is recoverable, but it is the responsibility of the caller to implement its own retry mechanism.
It is potentially recoverable but the exact recovery strategy tends to be application specific.
The retry isn't built-in to the http client code itself but the recovery of the internally managed connection is handled by the http client. Is that right?
No, it is not. There a default retry-mechanism in place but it applies to idempotent methods only. Please take a look at DefaultHttpRequestRetryStrategy. HttpClient should automatically re-try idempotent methods, but non-idempotent method recovery is application specific and is considered a responsibility of the caller.
ConnectionClosedException is presently handled as non-recoverable by default. I am actually not sure this should be the case, but this is how it is now.
@Michael, do you happen to remember why we ended up treating ConnectionClosedException as non-recoverable?
However, It is always advisable to have one's own application specific recovery strategy.
Also, a small follow-up question about the TTL, how is it related (or not)to ConnectionConfig.setValidateAfterInactivity,
Validate-after-inactivity and total-time-to-live are unrelated. Both, however, can cause the connection to be considered expired.
and are those two related
to client's builder evictIdleConnections method?
Those two settings are unrelated to idle connection eviction. A connection can be perfectly valid but it stays idle too long, it can get dropped.
Between idleness, TTL, and validation, what is supposed to be the correct way to use these three configurations together?
This is entirely up to the caller. One may want to have a fairly long TTL, say 15 minutes, to ensure connections get refreshed every once in a while. The validate-after-inactivity check is not cheap. One should use it sparingly. It is usually up to the caller to decide, what is more preferable, a certain performance hit due to the validate-after-inactivity check or an occasional i/o exception due to the connection being stale. What connections are considered idle is entirely up to the caller.
Oleg
On Wed, Mar 13, 2024 at 5:14 AM Oleg Kalnichevski <ol...@apache.org> wrote:On Tue, 2024-03-12 at 21:58 -0400, Jonathan Amir wrote:Hello, I am building an HTTP/2 only client for running multiple requests in parallel. I understand that there is no connection pool internally, rather there is one connection per host. For simplicity, let's say all my requests go to the same host.This is correct. It is still technically a pool though (per host basis).I have a situation where under stress there are some errors. It starts with socket timeout (several threads in parallel), and after a while there is a ConnectionClosedException.Even though HTTP/2 has a proper connection termination handshake, the handshake is potentially racy. Under high load ConnectionClosedException can and will happen. Your application code must be prepared to handle those.I am not sure what is the flow of events that leads to this, and what is the relationship between those errors. I also don't know if it is my client or the server that closed the connection.It, of source, would help greatly to know what exactly happens and leads to ConnectionClosedException.My initial question is, since there is only one connection maintained internally, how does one recover from ConnectionClosedException? The connection life-cycle is opaque to me - there is no pool, and no eviction strategy, so no concept of creating a new connection. So what am I missing? Is the httpClient object still usable after a ConnectionClosedException?The internal connection pool can automatically re-establish closed connection once the connection termination handshake completes or the connection gets dropped abnormally.Somewhat related, I am looking at the sample here:https://hc.apache.org/httpcomponents-client-5.3.x/migration-guide/migration-to-async-http2.htmlWhat is the difference between the two socket timeout configurations, on IOReactorConfig and ConnectionConfig?Both represent the same timeout but apply at different levels. IOReactorConfig apply at the i/o reactor level and are specific to the async i/o model. ConnectionConfig apply at the connection management level and is not specific to any i/o model.What is the time to live?You mean TTL, total time to live? The maximum period of time connections can be kept alive and re-used. Once past TTL connections get automatically closed out. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
--------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
