RE: Stale Connection Check
On Tue, 2011-03-29 at 23:11 -0500, Vadheraju, Rajeshwar wrote: Oleg, Thanks for your response. We can't upgrade to 4.1 in a day or two as the mentioned errors are occurring in Production environment. We will consider moving to 4.x in near future(may be in the next release), thanks for your suggestion. I went through link that you provided , In 2.10. Connection eviction policy, it reads like ...The stale connection check is not 100% reliable... So my question is why stale connection check is not reliable, doesn't matter whether it is version 3.1 or 4.x? HTTP connection can be closed by either endpoint and become 'stale' on the opposite end at any given moment. There is always a window, albeit small, between a successfully completed stale connection check and flushing of the internal session buffer containing the outgoing request message, in which the underlying connection can become stale without Httpclient's noticing until it is too late. I would go as far as saying that the stale connection check is useless and evil. It by no means can be used as a substitute for a sensible request retry / recovery mechanism. Hope this helps Oleg - To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
RE: Stale Connection Check
Thanks, Oleg. If I implement retry, It may resolve #1 of 3 issues that I have. Again, I was running into 1) Connection Reset - Client is trying write/send a request, connection broken - retry perfectly work 2) Broken Pipe - Client is trying to read the response from server, connection broken. In this situation, If I retry, I see HttpClient retries entire request, which could cause server to receive duplicate requests, which is not desirable. 3) Server failed to respond error - NoHttpResponseException - I think it is similar to #2 above. -Original Message- From: Oleg Kalnichevski [mailto:ol...@apache.org] Sent: Wednesday, March 30, 2011 9:10 AM To: HttpClient User Discussion Subject: RE: Stale Connection Check On Tue, 2011-03-29 at 23:11 -0500, Vadheraju, Rajeshwar wrote: Oleg, Thanks for your response. We can't upgrade to 4.1 in a day or two as the mentioned errors are occurring in Production environment. We will consider moving to 4.x in near future(may be in the next release), thanks for your suggestion. I went through link that you provided , In 2.10. Connection eviction policy, it reads like ...The stale connection check is not 100% reliable... So my question is why stale connection check is not reliable, doesn't matter whether it is version 3.1 or 4.x? HTTP connection can be closed by either endpoint and become 'stale' on the opposite end at any given moment. There is always a window, albeit small, between a successfully completed stale connection check and flushing of the internal session buffer containing the outgoing request message, in which the underlying connection can become stale without Httpclient's noticing until it is too late. I would go as far as saying that the stale connection check is useless and evil. It by no means can be used as a substitute for a sensible request retry / recovery mechanism. Hope this helps Oleg - 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. _
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
Re: Stale Connection Check
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
RE: Stale Connection Check
Oleg, Thanks for your response. We can't upgrade to 4.1 in a day or two as the mentioned errors are occurring in Production environment. We will consider moving to 4.x in near future(may be in the next release), thanks for your suggestion. I went through link that you provided , In 2.10. Connection eviction policy, it reads like ...The stale connection check is not 100% reliable... So my question is why stale connection check is not reliable, doesn't matter whether it is version 3.1 or 4.x? -Original Message- From: Oleg Kalnichevski [mailto:ol...@apache.org] Sent: Tuesday, March 29, 2011 2:05 PM To: HttpClient User Discussion Subject: RE: Stale Connection Check On Tue, 2011-03-29 at 14:00 -0500, Vadheraju, Rajeshwar 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. -R Please consider upgrading to the latest supported version of HttpClient, which is 4.1.1. If you still have questions after reading this tutorial, I will happily answer them. http://hc.apache.org/httpcomponents-client-ga/tutorial/html/ Oleg - 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. _
