[email protected] wrote:
Please validate this statement.
The IdleConnectionHandler kept firing past 20 seconds (my configured
timeout value) because that connection was still active and waiting for
data.
So it wasn't the IdleConnectionHandler that closed the socket, otherwise
I would have seen the following message "Closing connection, connection
time:".
Sounds about right.
As far as HttpClient is concerned any connection that is being used for
transmitting messages is considered active. Connections are considered
idle only when returned to the pool and not used for a certain period of
time.
Oleg
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.");
this.conn.close();
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
attempted");
throw e;
}
Thanks for all of your input Oleg.. It is much appreciated.
-----Original Message-----
From: Oleg Kalnichevski [mailto:[email protected]]
Sent: Wednesday, November 25, 2009 5:12 PM
To: HttpClient User Discussion
Subject: Re: HttpConnection.isResponseAvailable
[email protected] 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
a
slightly different issue but stemming from the same apparent
underlying
call.
Both the previous issue and this one are both sitting idle at a call
to
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
continuing
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.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
