How to not get a 504 Gateway timed out error?

Not applicable

I am an Apigee Edge Public Cloud user. One of my proxies involves many service callouts and is taking more than 1.5 minutes to return. However I can see the proxy going through in my trace , however I am returned a 504 Gateway timed out response in postman client /curl. How can I avoid this ?

Solved Solved
0 8 12.1K
1 ACCEPTED SOLUTION

@AlayVakil,

Thanks for sharing the org, env and proxy name details.

I had a look and basically this is what is happening:

1. The timeout values are set on the runtime components for your org/env as follows:

ELB (60secs) > Router (57secs) > Message Processor (55secs)

2. There is no target server in your API Proxy.

3. Since the Service Callout policy takes longer time, the timeout value on the Message Processor doesn't come into effect. The Message Processor continues to wait till the Service Callout policy completes its execution and therefore you will see a 200 successful response in the UI trace.

Note: The timeout on Message Processor will come into effect only if there is a target server defined in the target end point.

4. However, since the router has got a timeout value of 57 seconds, you will get a 504 Gateway timeout error in your curl/Postman output after 57 seconds are elapsed.

Possible solutions are:

1. Check if you can modify your Service Callout so that it can complete its execution faster (<57 secs).

2. If #1 is not possible, then the other alternative is to increase the timeout value on all the runtime components to a suitable higher value.

Note: Solution #2 will affect all the API Proxies in your org/env.

Request you to open a Apigee Support Ticket if you decide to take the option #2. We will be glad to assist you.

Regards,

Amar

View solution in original post

8 REPLIES 8

@AlayVakil , See similar question here. As you said "One of my proxies involves many service callouts and is taking more than 1.5 minutes to return", It might be as per design & timeout thresholds in Apigee Edge is getting activated.

Most probably some of the backends might not be reachable from Edge & Gateway timesout with 504 error. Please verify endpoints in service callouts & make sure overall API request processing in Edge doesn't cross the thresholds.

Hope it helps. Keep us posted if any.

@AlayVakil

Typically the timeout values on the below Edge components are set in a decreasing order as shown below:

ELB (60secs) > Router (57secs) > Message Processor (55secs)

Note: Default values are shown within the braces.

So if a service callout takes longer time, ideally the Message Processor should have timed out and caused 504 Gateway timeout. However, as per your description, the proxy runs successfully in the trace, but you get 504 Gateway Timeout in Postman/curl. This indicates that Message Processor did not timeout, but either the router or ELB (if available) timed out.

This can happen if:

a) The timeout value on the Message Processor is greater than the timeout value on Router/ELB

OR

b) The io.timeout.millis property is set with a value greater than the timeout value in the Target Endpoint within the API Proxy. (This value can only override the timeout value of the Message Processor)

The best practice is to ensure the timeout values on the components are set as explained above, so that you get the same results both in the trace and curl output.

(If you can share the org/env and API Proxy name by using "Ask an Expert", I can check and suggest what needs to be done for this.)

Having said that, to get rid of 504, you have to check which of your service callout policies is taking longer and check why the corresponding backend server is taking longer time.

Regards,

Amar

Great Answer @AMAR DEVEGOWDA , + 1

Hey Amar,

I have used the ask expert option and provided the details. Could you please help me out ?

Thank you ,
Alay

Hi Alay,

Thanks for giving the requested information. I will look into it today and get back to you.

Regards,

Amar

@AlayVakil,

Thanks for sharing the org, env and proxy name details.

I had a look and basically this is what is happening:

1. The timeout values are set on the runtime components for your org/env as follows:

ELB (60secs) > Router (57secs) > Message Processor (55secs)

2. There is no target server in your API Proxy.

3. Since the Service Callout policy takes longer time, the timeout value on the Message Processor doesn't come into effect. The Message Processor continues to wait till the Service Callout policy completes its execution and therefore you will see a 200 successful response in the UI trace.

Note: The timeout on Message Processor will come into effect only if there is a target server defined in the target end point.

4. However, since the router has got a timeout value of 57 seconds, you will get a 504 Gateway timeout error in your curl/Postman output after 57 seconds are elapsed.

Possible solutions are:

1. Check if you can modify your Service Callout so that it can complete its execution faster (<57 secs).

2. If #1 is not possible, then the other alternative is to increase the timeout value on all the runtime components to a suitable higher value.

Note: Solution #2 will affect all the API Proxies in your org/env.

Request you to open a Apigee Support Ticket if you decide to take the option #2. We will be glad to assist you.

Regards,

Amar

Hey Amar ,

Can we not increase the timeouts at the proxy level and not organization wide ?

@AlayVakil,

I am afraid there is no proxy level timeout setting that will control the timeouts on all the runtime components (ELB, Router, MP). The only way would be to increase the timeout on all the runtime components.

Regards,

Amar