setting http connection timeout httpClient in JS

[yassertaeima]

Currently we are using httpClient object in JS as described in

https://docs.apigee.com/api-services/reference/javascript-object-model#makingjavascriptcalloutswithh...

I am trying to figure out if there is a way to set a timeout on the http connection. I am referring to abandoning the connection if the connect/send/receive takes more than x number of milliseconds.

I understand that httpClient is async, but still we are concerned about the number of (async) threads this will create if the Target of the httpClient is slow in response and the load it will create on the MP.

The API, which is using the httpClient in JS, is heavily used and we want to make sure that a slow connection does not result in a high number of (async) threads waiting for the target of the httpClient to respond.

I see there is a waitForComplete(x) on the object httpClient returns, but it defeats the purpose of the (async), if we wait to set the timeout and kill the http connection thread.

Is there a way to set a timeout on the httpClient Request or the exchange object it creates?

[#2]

AFAIK, the httpClient.send() times out by default after a few seconds. I don't know, however, if/where i can be configured.

Also I think you're missing the pattern httpClient is suposed to be used on:

You could simply waitForComplete(x) on a later step of your proxy (on the step you need the response data or error), being x the max timeout you're willing to wait for it to complete.

An alternative, if you need promise-like behavior, is to use a nodejs proxy.

Another possible choise would be to use a Java callout.

Do you want to explore deeper one of theese paths?

[yassertaeima]

Thanks @Mauricio Navarro Miranda

does the waitForComplete(x) terminate the Async thread when x is reached, or would it just continue after x is reach and leave the thread to finish on its own time?

This will be called from a heavy traffic proxy and the other end of the httpClient is a small low performance server (outside of our control).

Our concern is the server at the end of the httpClient calls takes on a log time to establish the connect and receive the data, which will result in a large number of (async threads) on the MP consuming resources

For example,

If the thruput on the primary proxy is 100/sec (which generates 100 async httpClients per sec)

and the httpClient is taking 2 seconds to close each thread, then we will end up with a very large number of httpClients that will keep growing over time as we are generating httpClients requests at a rate higher than the httpClient processing time.

This is why we are looking for some way to limit the processing time of the async thread so it doesn't go out of control.

if that's not possible from the httpClient then we will move it to NodeJS where there is more controll over the http request

[#4]

In that case you may need to explore other apigee capabilities to avoid a bad performance or bad user experience, and not rely only on timeouts.

The MP resources are there to use them. Sure, you must ensure to do a optimal usage of them, but if I need to tradeoff between a few megabytes of RAM loaded onto MP or a bad user experience, most of the times I'll go for the megabytes, if that ensures me a smooth user experience.

Would it be a good path, for instance, to cache requests/responses to/from target server?
Apigee has cache policies that will help you if you decide to go this way.

[yassertaeima]

Thanks @Mauricio Navarro Miranda

Caching is not relevant in this case as the async process is more of a notification event.

It is not about adding additional resources, it is more about controlling the processors and insuring that they are not creating rouge (uncontrolled) async processes that are increasing in number exponentially as the thuput increases on the proxy.

We will remove the async process for now and later probably add it into dedicated NodeJS or dump the data into a file using MessageLogging and then process the file externally outside apigee.