> > You can just close the response. If response content has not been fully > consumed CloseableHttpResponse#close will NOT attempt to salvage the > underlying connection and will simply shut it down and release it back > to the pool in a non-reusable state. > > Think of CloseableHttpResponse#close as a safe-guard for 'unhappy' > execution flows. >
Thanks. I did see close getting called during execution retries, and wondered why that was a "special" case. Out of curiosity, why return the connection to the pool in a non-reusable state, as opposed to just dropping it from the pool? > > Connection pools cannot end up in a shutdown state by itself. They must > be explicitly shut down. There has to be something in your code that > shuts the pool down. > Yeah, clearly. I'm still hunting that down. > No, it is not. By default the connection manager attempts to close > connections out gracefully, which especially in case of SSL connections > can be a lengthy operation. > I was closing the connections in a background thread, but it appears in some cases that a long-running close in that thread can hang the process. I'm investigating alternatives. Thanks for the great response. -- Todd
