Backend timeout looks like a request timeout
See original GitHub issueThe timeout defined in the backend section seems to be a timeout for the entire request. If I configure it lower than the time required to get the full response, but fast enough to get the template from the backend I get errors like:
Timeout exceeded, failed to respond in 100ms. Failed Fragment: http://XXX/account/
The fragment timeout however is set much higher in the template:
<div cx-url="{{server:status}}/account/" cx-timeout="4s">
</div>
Issue Analytics
- State:
- Created 7 years ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
408 Request Timeout - HTTP - MDN Web Docs
The HyperText Transfer Protocol (HTTP) 408 Request Timeout response status code means that the server would like to shut down this unused ...
Read more >How to implement a request timeout using the Promise.race ...
When fetching, the frontend is decoupled from the backend, and the frontend fetches the data from the backend (usually in JSON format). Many...
Read more >Backend server timeout
The default timeout value for the timeout value is 60000 ms (60 seconds) as shown below: [execute][Sending request to backend ...
Read more >Setting a Request Timeout for a Spring REST API - Baeldung
Configuring different request timeouts for different backend services may be necessary, and is possible with this solution. Also, the Mono or ...
Read more >504 Gateway Timeout from Backend Server | Apigee Edge
Apigee Edge expects a response for every API request within a time period based on the timeout values. If the response is not...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks, merged and published today.
From memory it was a safety net, a way to ensure it never got stuck or took too long (which under load would stack requests up and take the whole thing down).
It may be better to have the backend timeout be for the request to the backend, and perhaps add an optional parserTimeout that could be added if you wanted the larger timeout to be enabled?