For each incoming request, we want Kong to return a response after a maximum of 60 seconds.
Therefore, we are using the
Service entity default values for
retries attribute is also set to the default of 5.
However, if the
upsteam is not responding within 60 seconds, Kong will try again - up to 5 times. In this case, Kong returns a response to the client only after 60*6 seconds…
We can set the
retries attribute to 0 to fix this but then we will miss the benefit of the retry in case of poor connection etc’.
Is there an option to set up a timeout for the whole request process including retries? Or maybe to restrict the retries mechanism only to failures that are not timeout?
The point to note is that by default Kong only retries for connection timeouts. So you can do the math and set this up accordingly.
I’ve a question for you, what did you expect Kong to rety on other than timeouts?
Thanks for the answer.
I have created an upstream server with an endpoint that responds only after 30s (using sleep) and set Kong’s ‘read_timeout’ for this service to 15s.
I noticed that once the ‘read_timeout’ ended, Kong sent another request and so on - according to the specified
Therefore, I concluded that Kong also retries on ‘read_timeout’. Is that correct? If not, what is the explanation for this behavior?
Kong will retry for connect and read timeouts (as defined on Service object in Kong) while communicating with upstreams.
I’m not sure what is the behavior of write timeouts.