Hi, Sure, I will. If I want to provide a patch do I have to do it on the 4.0.x branch or trunk ?
Thanks, -- Olivier 2010/1/6 Oleg Kalnichevski <ol...@apache.org>: > Olivier Lamy wrote: >> >> Sure. >> It's just I found this more elegant/readable code using the retry >> handler mechanism rather than writing catch/loop as with http client >> 3.x. >> > > While I agree with Ken that retrying requests on ConnectTimeoutException > feels wrong, it is certainly incorrect that retry handler is not called. > Feel free to open a JIRA for this issue. > > Oleg > >> -- >> Olivier >> >> 2010/1/6 Ken Krugler <kkrugler_li...@transpac.com>: >>> >>> On Jan 6, 2010, at 12:49pm, Olivier Lamy wrote: >>> >>>> NO. >>>> ConnectionTimeOutException can means the target endPoint cannot be >>>> contacted. >>>> >>>> My software "POST" some datas to various systems : company ones and >>>> externals one. >>>> Sometimes some systems are on small maintenance mode or during a >>>> restart time or some other stuffs. >>>> What I like is to not failed directly the application and try some >>>> retries with a sleep period between. >>> >>> Having long delays deep in the bowels of the request handling code feels >>> wrong. >>> >>> If you need long sleep periods, then I'd wrap the entire POSTing process >>> with a catch/retry loop, versus trying to leverage some retry support >>> inside >>> of HttpClient. >>> >>> -- Ken >>> >>>> With this I can give a chance to the target systems to be live before >>>> : shutdown my application, having a kind of system alarm which will >>>> wake some folks (including probably myself) maybe during the nigth. >>>> All of this only because someone has restarted a server somewhere >>>> without any notifications. >>>> >>>> IMHO it's a good use case :-)) >>>> >>>> -- >>>> Olivier >>>> >>>> 2010/1/6 Ken Krugler <kkrugler_li...@transpac.com>: >>>>> >>>>> From my experience, you get a ConnectTimeoutException when you've made >>>>> a >>>>> configuration or implementation mistake. E.g. >>>>> >>>>> - your connection pool size isn't big enough given the number of >>>>> simultaneous threaded requests. >>>>> - you're not releasing connections properly (e.g. when aborting a >>>>> request) >>>>> >>>>> So having an auto-retry is kind of odd here - if you want to avoid the >>>>> timeout, fix the root problem. >>>>> >>>>> -- Ken >>>>> >>>>> >>>>> On Jan 6, 2010, at 12:27pm, Olivier Lamy wrote: >>>>> >>>>>> Thanks for reply. >>>>>> Yes I already use this for this type of exception. >>>>>> But this doesn't catch the ConnectionTimeOut. >>>>>> >>>>>> -- >>>>>> Olivier >>>>>> >>>>>> 2010/1/6 Khosro Asgharifard <khosro_quest...@yahoo.com>: >>>>>>> >>>>>>> Hi all, >>>>>>> Olivier , Maybe i could not answer your question but i have one >>>>>>> question >>>>>>> . >>>>>>> Sometimes i got the "Read timeout" or "Connection reset" or >>>>>>> "Stream close" exceptions . >>>>>>> and "Read timeout" exception is the most one. >>>>>>> How do you use HttpRequestRetryHandler to handle "Read timeout" >>>>>>> exception ? >>>>>>> I use this code ,but again i got this "Read timeout" exception , >>>>>>> >>>>>>> GetMethod httpGet = new GetMethod(url); >>>>>>> httpGet.getParams().setParameter(HttpMethodParams.RETRY_HANDLER, new >>>>>>> DefaultHttpMethodRetryHandler(10, true)); >>>>>>> >>>>>>> Is there another way to handle this exception? >>>>>>> >>>>>>> Khosro. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Olivier Lamy <ol...@apache.org> >>>>>>> To: httpclient-users@hc.apache.org >>>>>>> Sent: Wed, January 6, 2010 10:08:21 AM >>>>>>> Subject: Retry on ConnectTimeoutException >>>>>>> >>>>>>> Hi, >>>>>>> I'm using http-client 4.0.1. >>>>>>> Is there any way to use HttpRequestRetryHandler to handle retry on >>>>>>> ConnectTimeoutException ? (I did it with http client 3 ) >>>>>>> >>>>>>> Thanks, >>>>>>> -- >>>>>>> Olivier >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: >>>>>>> mailto:httpclient-users-unsubscr...@hc.apache.org >>>>>>> For additional commands, e-mail: >>>>>>> mailto:httpclient-users-h...@hc.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olivier >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org >>>>>> For additional commands, e-mail: httpclient-users-h...@hc.apache.org >>>>>> >>>>> -------------------------------------------- >>>>> Ken Krugler >>>>> +1 530-210-6378 >>>>> http://bixolabs.com >>>>> e l a s t i c w e b m i n i n g >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org >>>>> For additional commands, e-mail: httpclient-users-h...@hc.apache.org >>>>> >>>>> >>>> >>>> >>>> -- >>>> Olivier >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org >>>> For additional commands, e-mail: httpclient-users-h...@hc.apache.org >>>> >>> -------------------------------------------- >>> Ken Krugler >>> +1 530-210-6378 >>> http://bixolabs.com >>> e l a s t i c w e b m i n i n g >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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 > > -- Olivier --------------------------------------------------------------------- To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org For additional commands, e-mail: httpclient-users-h...@hc.apache.org
