API gateway has a default 5 minutes timeout for an HTTP request. Some APIs need more or less time.
watt.net.timeout by default is 300 second= 5 Minutes changing it will change it globally
I tried changing the HTTP Connection Timeout & Read Timeout on the Straight Through Routing policy. Hoping it will do something, but it didn’t.
Please see the documentation here:
Administration - webMethods.io API
In particular…
pg.endpoint.connectionTimeout Specifies the time interval (in seconds) after which an HTTP connection attempt times out. Default: 30 seconds.
This is a global property that applies to the endpoints of all APIs. If you prefer to specify a connection timeout for the endpoints of an API individually, set the HTTP Connection Timeout parameter in the API’s Routing Protocols processing step, which would then take precedence over
pg.endpoint.connectionTimeout.The precedence of the Connection Timeout configuration is as follows:
If you specify a value for the Connection timeout field in routing endpoint alias, then the Connection timeout value specified in the Endpoint alias section takes precedence over the timeout values defined at the API level and the global level.
If you specify a value 0 for the Connection timeout field in routing endpoint alias, then API Gateway uses the value specified in the Connection timeout field in the routing protocol processing step of an API. The Read Timeout value specified at an API level takes precedence over the global configuration.
If you specify a value 0 or do not specify a value for the Connection timeout field in the routing protocol processing step at the API level or specify a value 0 at an alias level, then API Gateway uses the value specified in this
pg.endpoint.connectionTimeoutproperty.If you do not specify any value for
pg.endpoint.connectionTimeout, then API Gateway uses the default value of 30 seconds.
and here:
[Policies - webMethods.io API]( Policies - webMethods.io API)
HTTP Connection Timeout (seconds) Specifies the time interval (in seconds) after which a connection attempt times out.
The precedence of the Connection Timeout configuration is as follows:
- If you specify a value for the Connection timeout field in routing endpoint alias, then the Connection timeout value specified in the Endpoint alias section takes precedence over the timeout values defined at the API level and the global level.
- If you specify a value 0 for the Connection timeout field in routing endpoint alias, then API Gateway uses the value specified in the Connection timeout field in the routing protocol processing step of an API. The Read Timeout value specified at an API level takes precedence over the global configuration.
- If you specify a value 0 or do not specify a value for the Connection timeout field in the routing protocol processing step at the API level or specify a value 0 at an alias level, then API Gateway uses the value specified in this pg.endpoint.connectionTimeout property.
- If you do not specify any value for pg.endpoint.connectionTimeout, then API Gateway uses the default value of 30 seconds.
Along with this screenshot!
Thank you for replaying,
I have already tried doing that.
But I don’t think we are using any routing endpoint aliases. We are directly connecting to IS using reverse invoke.
I have changed
pg.endpoint.connectionTimeout to 0
And HTTP Connection Timeout on the Straight Through Routing to 60 sec.
I have also changed pg.endpoint.read timeout to 0 and the read Timeout on Straight Through Routing to 60 sec.
But the request does not terminate at 1 minute. Instead, it terminates at 5 minutes.
So, the timeouts on the Straight Through Routing are doing nothing.
Is the question in relation to Integration Server or API gateway?
The issue is related to API gateway
I just need the timeout of a specific API to be 1 minute instead of 5 minutes
The only thing that worked for me is playing around with watt.net.timeout but changing it will change the timeout globally
Can you explain this statement some more?
But I don’t think we are using any routing endpoint aliases. We are directly connecting to IS using reverse invoke.
I don’t really understand what you’re trying to achieve here with the IS connection/reverse invoke. A diagram or a more complete description of how the API is implemented might be useful.
If you’re connecting from API GW(IS) to another IS, timeouts will apply on both ends and may need to be configured accordingly.
I am just explaining that we are not using any endpoint aliases, so we are not specifying any connection timeout or read timeout.
I just tested this on my webmethods.io tenant.
I created an integration that runs for 30 seconds, exposed this as an API, and connected into the gateway.
If I do not set http timeouts on the routing policy, the API response is returned to the caller, invoking the API through the gateway end point.
However if I do set timeouts like the below:
I see this after the defined period:
So the timeouts on the API policies are working - but to be clear, that does not stop the call that is made to the downstream system… this would still run though to completion, so would also need appropriate timeout mechanisms in place on the source API.
Correct me if I’m wrong, but from your description, you’re not referring to the API Gateway with its API management feature. Instead, you seem to be referring to the reverse proxy (reverse invoke) function. The “old” Reverse Invoke Server (or Enterprise Gateway Server) function which is now bundled in with API GW, correct? To an internal Integration Server (not hosting API Gateway). Nothing about any of the API policies will impact this. Only the IS-level settings.
For the RIS function, connection timeout does not apply. Because the internal IS establishes the connection, not the gateway. When the GW receives request, it uses one of the available connections from the pool that was created when the internal IS opened 1-n connections (depending upon your configuration).
Is this what you’re referring to?
+1
I was wondering the same, but I’m struggling in my mind to understand the use case here.
I think it is a case where a call to a service hosted on an internal IS takes longer than the others – API GW/EGS/RIS will wait for a response for the configured timeout but that’s a global setting. I think the only option is the timeout needs to be the highest that is ever expected for any of the services reached via the gateway.
We hope user h-ask can clarify here that part 
TIA
RMG
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.
