hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <kenneth.s.bro...@chase.com>
Subject RE: HttpConnection.isResponseAvailable
Date Thu, 26 Nov 2009 18:09:35 GMT
Please validate this statement.

The IdleConnectionHandler kept firing past 20 seconds (my configured
timeout value) because that connection was still active and waiting for
So it wasn't the IdleConnectionHandler that closed the socket, otherwise
I would have seen the following message "Closing connection, connection

That makes sense now looking at the source, because it looks like
HttpMethodDirector caught an exception because that is where the stack
is reporting it.. 

                } catch (IOException e) {
                    LOG.debug("Closing the connection.");

and then just a little past that we see it saying that it did not retry
(I'm using a default retry handler) and throws the exception back to the
client.. which logged the Connection Reset.
                    if (!handler.retryMethod(method, e, execCount)) {
                        LOG.debug("Method retry handler returned false.
                                + "Automatic recovery will not be
                        throw e;

Thanks for all of your input Oleg.. It is much appreciated.

-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org] 
Sent: Wednesday, November 25, 2009 5:12 PM
To: HttpClient User Discussion
Subject: Re: HttpConnection.isResponseAvailable

kenneth.s.brooks@chase.com wrote:
> Related to previous post: Infinite loop in ChunkedInputStream.close
> Oleg,
> Last week I posted about an issue where we got the request body, and
> when close is called on the input stream it gets to the underlying
> InputStream.read and just sits there.
> We ran some more tests with httpclient wire logging on and we captured
> slightly different issue but stemming from the same apparent
> call.
> Both the previous issue and this one are both sitting idle at a call
> SocketInputStream.read (see the 'Client Log' further down this post
> showing the stack trace where it is sitting).
> From what I see below it looks like the reply started to come, we get
> the headers.. but it is sitting idle while checking for the response
> body.
> The VM isn't paused tho because the IdleConnectionHandler is
> to fire and (I think) eventually is responsible for closing the
> connection. That is why we aren't getting a connection reset from the
> loadbalancer in this case.
> So what in the world would would cause it to sit there?

The method blocks because the server is not sending any data whereas it 
clearly should be sending at least the closing chunk.

I do not see anything that could suggest there is a problem on the 
client side.


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

This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
 If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

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

View raw message