Alexander Weickmann
07/09/2019, 11:32 AMtseisel
07/09/2019, 1:49 PMHttpClient
, it also creates its HttpClientEngine
, which is Apache
in your case.
From HttpClientJvmEngine
, you can see that all JVM engines allocate a pool of threadsCount
daemon threads to execute requests in parallel, where threadsCount
can be changed in the engine { ... }
block (defaults to 4).
Closing an HttpClient
will at least cancel its pending requests and release its thread pool. Since those are valuable resources, you'd initialize the client once and reuse it as much as possible.Alexander Weickmann
07/09/2019, 3:57 PMengine {
customizeClient {
setConnectionReuseStrategy(NoConnectionReuseStrategy())
}
}
So there is no connection reuse, and the client always makes calls with a fresh connection that the target could not have hung up.
This seems more like a workaround to me, than a proper solution, though. I got the idea from this thread on github, which is similar but for netty: https://github.com/reactor/reactor-netty/issues/388
I also read somewhere else, that a connect reset by peer is a "valid use case" that clients should be prepared to deal with (by retry). So I am not sure whether I should wrap all my calls in a retry handler to deal with the problem (seems a bit weird?), or whether the disable connection reuse thing is better (performance impact?). Right now I am simply using whatever keeps my service stable ...