I found in the documentation steps to set the timeout value.
const instance = axios.create({
baseURL: 'https://some-domain.com/api/',
timeout: 1000,
headers: {'X-Custom-Header': 'foobar'}
});
But I could not find the default value in the official axios documentation - https://github.com/axios/axios
What is the default timeout?
Also, Underneath AXIOS uses http server/client (https://nodejs.org/api/http.html#http_class_http_clientrequest)
Does it use the http default timeout?
I see my program timesout after 2 minutes.
According to the README, it is 0 which means no timeout
// `timeout` specifies the number of milliseconds before the request times out.
// If the request takes longer than `timeout`, the request will be aborted.
timeout: 1000, // default is `0` (no timeout)
https://github.com/axios/axios/blob/master/README.md#request-config
Related
What is the way to timeout a cloudant HTTP request if it takes more than some seconds? I am using the cloudant library. For example, I am having a query that takes some 20 to 30 secs but I want to timeout the HTTP call if the response time is more than 15 secs.
You can configure the Cloudant client with requestDefaults one of the options is timeout e.g.
"requestDefaults": { timeout: 15000 }
I have an issue that Rest-Assured seems to issue a 2nd and 3rd call when the response takes more than 60 seconds. What I need is RestAssured to wait for the call to finish and not send more calls.
The simple test to an endpoint that takes more than 60 seconds to respond:
return given()
.relaxedHTTPSValidation()
.baseUri(cloudBaseurl)
.when()
.get(fullServicePath)
.then().extract().response();
The issue is that I see in the logging of the requested service that exactly 60 seconds later, a second call comes in and a 3rd after another 60 seconds. By default RestAssured seems to timeout after 3 minutes.
What I tried:
1. Setting different parameters
RestAssured.config= RestAssuredConfig.config().httpClient(httpClientConfig().
setParam("http.connection.timeout",70000).
setParam("http.connection.request.timeout",70000).
setParam("http.socket.timeout",70000).
setParam("http.connection-manager.timeout",70000).
setParam("http.conn-manager.timeout",70000L).
setParam("http.connection.stalecheck",false).
setParam("http.keepAlive",70000L));
It does timeout after 70 seconds, but still after 60 seconds the 2nd call comes in.
2. Setting headers in RestAssured
return given()
.relaxedHTTPSValidation()
.baseUri(cloudBaseurl)
.header(HttpHeaders.CONNECTION,"Keep-Alive")
.header("Keep-Alive","timeout=100", "max=180")
.when()
.get(fullServicePath)
.then().extract().response();
No change. Still a 2nd request after 60 seconds.
3. Changing the default request behavior (as suggested here: HttpClient executes requests multiple time if request timed out)
RestAssured.config = RestAssured.config().httpClient(httpClientConfig().httpClientFactory(
() -> {
SystemDefaultHttpClient systemDefaultHttpClient = new SystemDefaultHttpClient();
ClientConnectionManager connectionManager = systemDefaultHttpClient.getConnectionManager();
connectionManager.closeIdleConnections(100, TimeUnit.SECONDS);
// Disable default behavior of HttpClient of retrying requests in case of failure
((AbstractHttpClient) systemDefaultHttpClient).setHttpRequestRetryHandler(new DefaultHttpRequestRetryHandler(0, false));
return systemDefaultHttpClient;
}));
I was looking in the wrong direction.
The timeout on the Ingress in Kubernetes needed to be increased. Adding the following to the Kubernetes deployment yaml solved the issue.
metadata:
name: your-service-name
labels:
app: your-service-name
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/proxy-connect-timeout : "3600"
nginx.ingress.kubernetes.io/proxy-read-timeout : "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout : "3600"
I went to the documentation and found out these
# The time after which an idle connection will be automatically closed.
# Set to infinite to completely disable idle connection timeouts.
idle-timeout = 10 s
# Defines the default time period within which the application has to
# produce an HttpResponse for any given HttpRequest it received.
# The timeout begins to run when the *end* of the request has been
# received, so even potentially long uploads can have a short timeout.
# Set to `infinite` to completely disable request timeout checking.
#
# If this setting is not `infinite` the HTTP server layer attaches a
# `Timeout-Access` header to the request, which enables programmatic
# customization of the timeout period and timeout response for each
# request individually.
request-timeout = 20 s
I have a scenario where my server takes more than 10 seconds to process a response but before sending the HTTPResponse the TCP connection between the client and server is timed out because of idle timeout.
Although the connection is idle at the moment but the request is still processing.
I thought this was the responsibility of response timeout?
Can anyone in this context explain me the difference between idle-timeout and response-timeout?
Documentation is a bit confusing, I have run the experiments based on that :
idle-timeout: It is the max time a connection can sit idle. It behaves the same as the Request timeout. Example :
idle-timeout = 1 s
Application has sent a request to 3rd party API and connection established, But 3rd party is not responding back. Then you will get a Timeout exception.
"akka.stream.scaladsl.TcpIdleTimeoutException"
connecting-timeout: 500 ms. It indicates the maximum time (500 ms) in which an Http connection must be established.
From the documentation and more details here
# The idle timeout for an open connection after which it will be closed
# Set to null or "infinite" to disable the timeout, but notice that this
# is not encouraged since timeout are important mechanisms to protect your
# servers from malicious attacks or programming mistakes.
idleTimeout = 75 seconds
If looks like you are setting the idle timeout lower than the request timeout, so it takes precedence. Your idle timeout settings should be longer than the request timeout, so for each request, the request timeout decides when to close the connection.
The spray-can docs comment on the spray.can.server.* and spray.can.client.* config settings:
spray.can.server {
# The time after which an idle connection will be automatically closed.
# Set to `infinite` to completely disable idle connection timeouts.
idle-timeout = 60 s
# If a request hasn't been responded to after the time period set here
# a `spray.http.Timedout` message will be sent to the timeout handler.
# Set to `infinite` to completely disable request timeouts.
request-timeout = 20 s
spray.can.client {
# The time after which an idle connection will be automatically closed.
# Set to `infinite` to completely disable idle timeouts.
idle-timeout = 60 s
# The max time period that a client connection will be waiting for a response
# before triggering a request timeout. The timer for this logic is not started
# until the connection is actually in a state to receive the response, which
# may be quite some time after the request has been received from the
# application!
# There are two main reasons to delay the start of the request timeout timer:
# 1. On the host-level API with pipelining disabled:
# If the request cannot be sent immediately because all connections are
# currently busy with earlier requests it has to be queued until a
# connection becomes available.
# 2. With pipelining enabled:
# The request timeout timer starts only once the response for the
# preceding request on the connection has arrived.
# Set to `infinite` to completely disable request timeouts.
request-timeout = 20 s
However, I also see that there's an implicit Timeout that can be passed to sendReceive.
Does setting any of the above config values result in a clash/override of the implicit Timeout? In short, I'm trying to understand the distinction between sendReceive's implicit time-out and the above config values.
In my src/main/resources/application.conf I include:
spray.can.server {
request-timeout = 1s
}
In order to test this, in the Future which is servicing my request I put a Thread.sleep(10000).
When I issue a request, the server waits 10 seconds and responds with no hint of a timeout being sent to the client.
I am not overriding the timeout handler.
Why are my clients (chrome and curl) not receiving a timeout?
The configuration looks correct, so Spray request timeout should be working. One of the frequent reasons for it not working is that your config application.conf is not being used by the application.
The reasons for config being ignored could be that it's in the wrong place, not included in your classpath, or not included in a JAR that you package.
To troubleshoot first check that default Spray timeout is working. By default it's 20 sec. Make your code sleep for 30sec and see if you get timeouts triggered.
Check what's in your final config values by printing it. Set this in your conf:
akka {
# Log the complete configuration at INFO level when the actor system is started.
# This is useful when you are uncertain of what configuration is used.
log-config-on-start = on
}
Finally, keep in mind other timeouts like timeout-timeout = 2 s.
I think the request-timeout is for the http client, if the response is not returned before that value, the client will get a timeout from spray, see the spary doc
# If a request hasn't been responded to after the time period set here
# a `spray.http.Timedout` message will be sent to the timeout handler.
# Set to `infinite` to completely disable request timeouts.
For example, in my web browser, I can got a below message:
Ooops! The server was not able to produce a timely response to your request.
Please try again in a short while!
If the timeout is long enough, the browser will keep waiting until a response is returned