![]() Timeout the request from requester - Need to set timeout header ( see the header configuration in requesting library).So, I thought to write it down so someone visiting here in future does not need to randomly check each answer and get success without knowing which worked. It can be seen that each answer is focused on only one aspect of these possibilities. We will be glad to assist you.There are three kinds of timeouts which can occur in such a case. Request you to open a Apigee Support Ticket if you decide to take the option #2. 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 for sharing the org, env and proxy name details. (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.) 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. (This value can only override the timeout value of the Message Processor) This indicates that Message Processor did not timeout, but either the router or ELB (if available) timed out.Ī) The timeout value on the Message Processor is greater than the timeout value on Router/ELBī) The io.timeout.millis property is set with a value greater than the timeout value in the Target Endpoint within the API Proxy. However, as per your description, the proxy runs successfully in the trace, but you get 504 Gateway Timeout in Postman/curl. ![]() So if a service callout takes longer time, ideally the Message Processor should have timed out and caused 504 Gateway timeout. Note: Default values are shown within the braces. We will be glad to assist the timeout values on the below Edge components are set in a decreasing order as shown below:ĮLB (60secs) > Router (57secs) > Message Processor (55secs) ![]() Note: Solution #2 will affect all the API Proxies in your org/env. 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. Check if you can modify your Service Callout so that it can complete its execution faster (<57 secs).Ģ. 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.ġ. Note: The timeout on Message Processor will come into effect only if there is a target server defined in the target end point.Ĥ. 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. Since the Service Callout policy takes longer time, the timeout value on the Message Processor doesn't come into effect. There is no target server in your API Proxy.ģ. The timeout values are set on the runtime components for your org/env as follows: ELB (60secs) > Router (57secs) > Message Processor (55secs)Ģ. I had a look and basically this is what is happening:ġ. For sharing the org, env and proxy name details.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |