hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: PoolingHttpClientConnectionManager and CloseableHttpResponse
Date Tue, 16 Sep 2014 08:30:02 GMT
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. 


>  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.


To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org

View raw message