On Mon, 2014-09-15 at 11:08 -0400, Todd W Lainhart wrote: > I'm seeing some IllegalStateExceptions (ISE) thrown from HC4 (4.3.5) in my > code, and suspect that I'm misusing the library. It happens sporadically, > probably when the JVM or the machine it's running on is under load. I > suspect non-thread-safe code (in my code). > > Perhaps related to this, I first want to confirm that I understand the > programming model for PoolingHttpClientConnectionManager (PHCCM) and > CloseableHttpResponse (CHR). > > CHR encapsulates both the response stream and the underlying network > connection.
Correct. > If I want to reuse the underlying connection for performance > reasons, my only responsibility is to consume the entity content of the > response. Correct. As soon as entity is fully consumed the underlying connection will be released back to the pool and kept alive (unless the connection is deemed non-persistent). In this case CloseableHttpResponse#close will have no effect. > If (for some reason) I don't want to reuse the underlying > connection, I both consume the response entity and close the CHR. 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. > This > behavior regardless of what type of HttpClientConnectionManager I'm using > (e.g. closing the CHR really does close it, as opposed to keep it open and > making it available in PHCCM). HttpClientUtils and EntityUtils provide > convenience routines for these behaviors. > > Do I have the programming model right? > Pretty much. > Regarding the ISE - when thrown, typically it's thrown from > PHCCM.requestConnection(...), when the AbstractConnPool is checking > whether or not the pool has been previously shutdown. So, the application > is in a state where something has told the connection manager to shutdown, > while there continue to be references to it. I see two places where > shutdown/close is called - in the close/finalizer methods of PHCCM, and in > the close method of InternalHttpClient. I can't see any other paths where > PHCCM and its pools could be shutdown. Note that I'm using my own > Registry<ConnectionSocketFactory>, to allow for custom socket factories > for "http" and "https". > 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. > Regarding shutting down the ConnectionManager - is this a relatively fast > operation or can it block based on the status of its underlying > connections? > 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. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
