API Connect

 View Only
  • 1.  API Gateway front-side times out in 60 seconds

    InnerCircle
    Posted Fri December 31, 2021 02:35 AM
    Edited by Rosh Fri December 31, 2021 02:58 AM
    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
    ------------------------------


  • 2.  RE: API Gateway front-side times out in 60 seconds

    InnerCircle
    Posted Wed January 26, 2022 07:52 AM
    Hi,
    Has anyone come across this type of behaviour and how was it resolved?

    ------------------------------
    Rosh
    ------------------------------



  • 3.  RE: API Gateway front-side times out in 60 seconds

    Posted Wed February 02, 2022 12:05 PM
    If the consumer can't send keep-alives within the 60 secs, you can modify the "WebSocket idle timeout" on the HTTPS Handler

    ------------------------------
    jeroen willems
    ------------------------------



  • 4.  RE: API Gateway front-side times out in 60 seconds

    InnerCircle
    Posted Thu February 03, 2022 02:27 AM
    Thanks Jeroen,
    This behaviour occurs on on HTTP requests and not a websocket

    ------------------------------
    Rosh
    ------------------------------



  • 5.  RE: API Gateway front-side times out in 60 seconds

    Posted Fri February 04, 2022 08:49 AM
    Hi there is a fixed timeout of 60 secs for the apigw to wait for the client to send the complete request ; that is to prevent a connection from hanging forever waiting for data.

    Once the client has sent all the data then that timeout should be canceled and the backend timeout is active.
    Depending on the configuration if the apigw is streaming then both timeouts may be active at the same time.
    So it is possible that the gateway is still waiting on some data from the client.

    ------------------------------
    Matthias Siebler
    MA
    ------------------------------



  • 6.  RE: API Gateway front-side times out in 60 seconds
    Best Answer

    Posted Wed June 01, 2022 06:17 PM

    To piggy back on Matthias' comment, I'd suggest you get a DataPower packet capture with ssl session keys so the traffic can be decrypted where you can see the incoming request into DataPower and the outbound request to your backend to see who is hanging up the connection.  You say "the front-side of the Gateway always times out and returns the error Connection aborted.', RemoteDisconnected('Remote end closed connection without response',)." but that error message, at least to me, sounds suspiciously like a backend connection issue where the backend closed the connection.  The packet capture will show what is going on at a network level.

    Regards,

    Steve



    ------------------------------
    Steve Linn
    Senior Consulting I/T Specialist
    IBM
    ------------------------------



  • 7.  RE: API Gateway front-side times out in 60 seconds

    Posted Tue June 14, 2022 12:16 PM

    Good morning Steve, we have validated what it tells us but we do not see that it is a disconnection from the backend;

    To validate that it was not the backend, what we did was test the sleep within a GatewayScript. If we put 59 seconds, it presents the output; but if we put more than 60 seconds it shows us the cors error

    We attach the code:

    function sleep(ms) {
    return new Promise(resolve => setTimeout(resolve, ms));
    }

    sleep(40000)

    console.error("No se")

    var apim = require('apim');
    apim.setvariable('message.body', 'Funciona')

    We remain attentive if you have any solution. Thank you



    ------------------------------
    Natalia Grajales
    ------------------------------



  • 8.  RE: API Gateway front-side times out in 60 seconds

    Posted Tue June 28, 2022 04:29 PM

    Hello,

    The solution for us, who had ApiConnect installed on OpenShift, was the following:

    In the OpenShift GatewayCluster parameters we update the apiDebugProbeExpirationMinutes parameter, although it had 60m configured, it counted us per sec

    This worked for us =)

    I hope it helps



    ------------------------------
    Natalia Grajales
    ------------------------------



  • 9.  RE: API Gateway front-side times out in 60 seconds

    Posted Fri May 27, 2022 12:54 PM

    Hello,
    We have the same behavior with version 10.0.4.0; were you able to solve it?

    Please advise. Thanks a lot.



    ------------------------------
    Natalia Grajales
    ------------------------------