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.  If (for some reason) I don't want to reuse the underlying 
connection, I both consume the response entity and close the CHR.  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?

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

Regarding shutting down the ConnectionManager - is this a relatively fast 
operation or can it block based on the status of its underlying 
connections?





Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email protected]

Reply via email to