Hi,
We have numerous APIs whose response time could take up to 180 seconds depending on the data being retrieved.
From our tests, we noticed the front-side of the API Gateway timing out at exactly 60 seconds in scenarios where the back-end(provider) may take over 60 seconds to respond.
To test this further, a simple API was developed containing an Invoke whose back-end timeout was set to 180 seconds (and higher).
On the Client(consumer) a timeout is not configured. The API is called by the client keeping the connection open while waiting for a response.
At exactly 60 seconds the front-side of the Gateway always times out and returns the error
Connection aborted.', RemoteDisconnected('Remote end closed connection without response',)
.
From the back-end logs and API Analytics, a response is eventually seen but it cannot be sent to the consumer as the front-side of the Gateway has already timed out.
This was done on v10.0.1.5-ifix3-39-eus. Similar behaviour was also been in earlier releases of v10 too.
The same test on v5 ran without an issue. Client always received a response when it was over 60 seconds.
This has been tested with the GET and POST methods and through various clients applications written in Python, Java and through other testing APPs like SoapUI, Postman and curl.
Is this normal behaviour of the Gateway to terminate an idle connection if no response is received within 60 seconds?
Setting a higher timeout on the invoke defeats the purpose if the front of the Gateway terminates the connection within 60 seconds.
The invoke timeout will only be useful in scenarios under 60s
How do cater for scenarios where response times are high?
Please advise.
------------------------------
Rosh
------------------------------