[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-1105.
-------------------------------------------

    Resolution: Fixed

Patch committed with some changes. I changed the signature of the 
ServiceUnavailableRetryStrategy to make it more consistent with 
HttpRequestRetryHandler. I also did not quite like recursive invocation of the 
#callBackend method. I replaced recursive method call with a simple loop.

Please review.

I also noticed that the default ServiceUnavailableRetryStrategy implementation 
was not fully thread safe. Ideally all instance variables in the 
DefaultServiceUnavailableRetryStrategy should be made final and the class 
should be made immutable.

Otherwise, many thanks for the contribution.

Oleg

> Built-in way to do auto-retry for certain status codes
> ------------------------------------------------------
>
>                 Key: HTTPCLIENT-1105
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1105
>             Project: HttpComponents HttpClient
>          Issue Type: Wish
>          Components: HttpClient
>    Affects Versions: 4.1.1
>            Reporter: Dan Checkoway
>            Priority: Minor
>             Fix For: 4.2 Alpha1
>
>         Attachments: patch_auto_retry.diff, patch_auto_retry_v2.diff
>
>
> The HttpRequestRetryHandler mechanism is great.  It allows API users to plug 
> in their own logic to control whether or not a retry should automatically be 
> done, how many times it should be retried, etc.  That works perfectly in 
> scenarios where an exception is caught while issuing the request.  It falls 
> short, however, in this scenario...
> If I'm hitting a service that returns a 503, I want to be able to retry that 
> request automatically as well.  As of right now, I need to write my own logic 
> to accomplish that, and it's clunky trying to integrate it with the 
> httpClient.execute() call, since it's my ResponseHandler impl that ends up 
> getting the 503.  I can see use cases for auto-retrying upon getting other 
> HTTP statuses as well, not just 503.
> My request here is...I would love to be able to configure, either on the 
> HttpClient itself or on a wrapping class or something, that a request should 
> automatically be retried if the HTTP status code is among of a set of 
> statuses that I configure.  It would be nice if you could set the max # of 
> retries, an optional sleep time in between retries (perhaps optional 
> incremental backoff if you want to get fancy).  I'm not sure if this is 
> possible, but it would be nice if -- when this type of status-based retry is 
> enabled -- my ResponseHandler wouldn't even get invoked until retry was 
> successful.
> Here's an alternative suggestion, possibly simpler to build, but definitely 
> not as elegant:
> In my ResponseHandler, you could throw a RetryRequestException or something 
> like that, and the calling code would catch that and do as expected.  That 
> might simplify the mechanism so to speak.
> Anyway, I would love not to have to roll my own retry code, since I suspect 
> this is something that hundreds (thousands?) of HttpClient users have had to 
> code.  Seems like providing a standardized, well-written way to do it would 
> go a long way to helping many coders out there.
> Thanks!

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to