Thanks again for the confirmation and input. -ken
-----Original Message----- From: Oleg Kalnichevski [mailto:[email protected]] Sent: Thursday, November 26, 2009 3:48 PM To: HttpClient User Discussion Subject: Re: HttpConnection.isResponseAvailable [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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
