Target API Retry policy when Target API has failures & service unavailable error from target endpoint

I am trying figure out how to setup proxy to do a Target API retry based on HTTP status code return from API. let's say only retry 3 times with 1 second interval when order code is 503 from Target API.

Got some reference community forum but not sure how exactly service call out should be used to do retry.

I am trying figure out how to setup proxy to do a Target API retry based on HTTP status code return from API. let's say only retry 3 times with 1 second interval when order code is 503 from Target API.

Got some reference community forum but not sure how exactly service call out should be used to do retry.

1 12 2,272
12 REPLIES 12

idea is like this:

client send a request to apigee api proxies, when target endpoint return a 503 service unavailable error, apigee api proxy wait for 500ms , then resend request to this target endpoint again, if it fail again on second attempt, then an error message will be returned back to client.

If I were doing this, I would use a Hosted Target (or a nodejs target).

Put the delay-then-retry logic in the nodejs script .

Here's a good way to do the retries in nodejs: https://stackoverflow.com/a/38225011/48082

Thanks for the quick reply. This means we need to handle it by putting some custom logic ... And that's usual/traditional approach to achieve this for any web-client . Dont we have anything in APIGEE ( any policy with little customization ) can do it ?

waiting for any other possible solutions...

@mysk online I also got some requirement like this where I have to retry a process 3 times in case of it fails with 502,503 or 504 issue due to any infrastructure or service unavailable issue. And we have to retry the same target 3times after that it will throw an error.
I want to implement using out of bound policy in APIGEE did you get any solution for this using javascript and service callout?

out of bound policy in APIGEE

?? What does this mean?

did you get any solution for this using javascript and service callout?

It's not possible, unless you use the JS script in place of the target. As you may know there is an httpClient available in the JS callout. You could script the httpClient to try 3 times to connect to a specific backend. In that case you wouldn't use the TargetEndpoint in the API Proxy.

No, there's no builtin retry logic in Apigee Edge for targets.

@Dino-at-Google can we implement it using javascript policy in case if we don't use node.js

It won't be possible in JavaScript (callout), but you could do it in Nodejs (hosted target).

@Dino-at-Google: Is this still the case - there is no delivered retry property that can be used to resend a call for a 503 or 504 error? We have a similar situation where a target back-end is not responding in time so a 504 gateway timeout error is thrown and we would like to configure a retry of the request. Is there any current recommendation on how to handle? Thank you.

Hi Lisa,

It would be "asking for trouble" to retry requests that fail with 503 or 504. The idea behind a 503 or 504 is, the server endpoint, or a gateway, is signaling an error. Often that error is caused by a resource shortage or problem at the server, or at the gateway.

Imagine that is the case. Imagine 10, 25, or 100 clients all sending requests. Apigee is proxying on their behalf and is receiving 503 or 504 errors. If Apigee immediately retried all of those requests, it would mean the server or gateway would get flooded with a cascade of additional requests, right when the server or gateway is broken or in the process of recovery.

The correct behavior of a client is to backoff (often exponentially), and only after a delay, retry the request. Apigee does not include an retry-after-exponential-backoff capability for a target.

I guess the correct thing to do is to handle the retry in the original client.

If you don't want to ask clients to do that, then you could wrap the target in a nodejs system (Hosted Target) and implement the exponential-backoff-and-retry , there.

What is the purpose of RetryEnabled feature within Load Balancing?

Per the doc, It retries when load balancing across distinct endpoints.

There must be a minimum of two target servers defined in the target endpoint configuration for retry to work.