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. 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?
Also, a small follow-up question about the TTL, how is it related (or not) to ConnectionConfig.setValidateAfterInactivity, and are those two related to client's builder evictIdleConnections method? Between idleness, TTL, and validation, what is supposed to be the correct way to use these three configurations together? 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.html > > What 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 > >
