On 29 March 2011 20:00, Vadheraju, Rajeshwar <rajeshwar.vadher...@fisglobal.com> wrote: > Oleg, Sorry if I sounded like forcing you to answer my question. I observed > that you are the only active person responding to the questions and really > hoping that you provide answers to my questions given your high expertise. I > read some of your other posts and your answers were crisp and clear. > > Sorry again - I would really appreciate if you could answer them.
This is open source - the code is available for you to inspect. Remember that this is a volunteer organisation, most committers do this work in their spare time. Also, consider that your original question was posed less than 24 hours ago. That does not give much time for others to respond. > -R > > -----Original Message----- > From: Oleg Kalnichevski [mailto:ol...@apache.org] > Sent: Tuesday, March 29, 2011 1:37 PM > To: HttpClient User Discussion > Subject: RE: Stale Connection Check > > On Tue, 2011-03-29 at 13:30 -0500, Vadheraju, Rajeshwar wrote: >> Oleg, Could you please respond to my questions? >> > > Rajeshwar > > This may sound harsh to you, but I no longer have any bandwidth nor > motivation for dealing with HC 3.1 related stuff. HC 3.1 is officially > end of life and is no longer being maintained or supported. > > Oleg > > >> -----Original Message----- >> From: Vadheraju, Rajeshwar [mailto:rajeshwar.vadher...@fisglobal.com] >> Sent: Monday, March 28, 2011 9:59 PM >> To: httpclient-users@hc.apache.org >> Subject: Stale Connection Check >> >> We are using httpclient 3.1 and I was reading httpclient documentation >> which mentions that the "stale connection check is not 100% guaranteed". >> I would like to get clarification on why it is not 100% reliable or >> guaranteed. What situations/scenarios make that stale check >> less-guaranteed? >> >> I am seeing below 3 errors in my logs. >> >> 1) Server failed to respond - NoHttpResponseException >> >> 2) Conneciton Reset >> >> 3) Broken Pipe >> >> >> >> For #1, I read the literature on web and found that "retry" is an >> option. But by looking at http client code, the "retry" is not just >> retying to get valid http connection, but retrying entire request(means >> entire request is re-sent) which could cause server to receive duplicate >> same requests, not desirable. And we are not running out of any worker >> threads or other resources. >> >> >> >> I started reading about IdleConnectionManager and the thread, not sure >> how do we implement it? And what are the benefits of removing idle >> connections from pool in the context of keep-alive persistent >> connection. >> >> >> >> -R >> >> _____________ >> >> The information contained in this message is proprietary and/or >> confidential. If you are not the intended recipient, please: (i) delete >> the message and all copies; (ii) do not disclose, distribute or use the >> message in any manner; and (iii) notify the sender immediately. In >> addition, please be aware that any message addressed to our domain is >> subject to archiving and review by persons other than the intended >> recipient. Thank you. >> _____________ >> >> _____________ >> >> The information contained in this message is proprietary and/or >> confidential. If you are not the intended recipient, please: (i) delete the >> message and all copies; (ii) do not disclose, distribute or use the message >> in any manner; and (iii) notify the sender immediately. In addition, please >> be aware that any message addressed to our domain is subject to archiving >> and review by persons other than the intended recipient. Thank you. >> _____________ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > > > _____________ > > The information contained in this message is proprietary and/or confidential. > If you are not the intended recipient, please: (i) delete the message and all > copies; (ii) do not disclose, distribute or use the message in any manner; > and (iii) notify the sender immediately. In addition, please be aware that > any message addressed to our domain is subject to archiving and review by > persons other than the intended recipient. Thank you. > _____________ > --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
