SetConnectTimeout vs. setConnectionTimeToLive vs. setSocketTimeout ()

Question

can someone explain what is the difference between the two:

client = HttpClientBuilder.create() .setConnectionTimeToLive(1, TimeUnit.MINUTES) .build(); 

and

 RequestConfig requestConfig = RequestConfig.custom().setConnectTimeout(30 * 1000).build(); client = HttpClientBuilder .create() .setDefaultRequestConfig(requestConfig) .build(); 

Is it better to use setSocketTimeout ?

Answer 1

Connection timeout: This is the time to wait until a connection to the server is established.

Socket timeout: This is the time of inactivity to wait for packets [data] to be received.

setConnectionRequestTimeout:

However, it is specific to configuring the connection manager. It is time to get the connection from the connection pool.

It returns the timeout in milliseconds used when requesting a connection from the connection manager. 0 (zero) is used for an infinite timeout.

setConnectionTimeToLive

public final HttpClientBuilder setConnectionTimeToLive (long connTimeToLive, TimeUnit connTimeToLiveTimeUnit)

Sets the maximum time for persistent connections

Note that this value can be overridden using the setConnectionManager(org.apache.http.conn.HttpClientConnectionManager) method setConnectionManager(org.apache.http.conn.HttpClientConnectionManager) .

C: 4.4

Example: HttpClientStarter.java

 @Override public boolean start() { RegistryBuilder<ConnectionSocketFactory> r = RegistryBuilder.<ConnectionSocketFactory> create(); // Register http and his plain socket factory final SocketFactory ss = getLevel().find(SocketFactory.class); ConnectionSocketFactory plainsf = new PlainConnectionSocketFactory() { @Override public Socket createSocket(HttpContext context) throws IOException { return ss.createSocket(); } }; r.register("http", plainsf); // Register https ConnectionSocketFactory sslfactory = getSSLSocketFactory(); if (sslfactory != null) { r.register("https", getSSLSocketFactory()); } else { log(Level.WARN, "ssl factory not found, won't manage https"); } HttpClientBuilder builder = HttpClientBuilder.create(); builder.setUserAgent(USERAGENT); builder.setConnectionTimeToLive(timeout, TimeUnit.SECONDS); builder.evictIdleConnections((long) timeout, TimeUnit.SECONDS); PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager(r.build()); cm.setMaxTotal(maxConnect * 2); cm.setDefaultMaxPerRoute(2); cm.setValidateAfterInactivity(timeout * 1000); builder.setConnectionManager(cm); RequestConfig rc = RequestConfig.custom() .setConnectionRequestTimeout(timeout * 1000) .setConnectTimeout(timeout * 1000) .setSocketTimeout(timeout * 1000) .build(); builder.setDefaultRequestConfig(rc); client = builder.build(); return true; } 

Resource Link:

• HttpClientStarter.java

• HttpClient 4.x Timeout

The HTTP specification does not specify how long a persistent connection can or should remain active. Some HTTP servers use the non-standard Keep-Alive header to tell clients how many seconds they want to stay on the server side. HttClient will take advantage of this if this information is available. If the Keep-Alive header information does not exist in the response, HttpClient assumes that the connection remains active indefinitely. However, many real-world HTTP servers are configured to disable persistent connections after certain periods of inactivity to conserve system resources, often without notifying the client.

Here you can rewrite one, here it is set 5 seconds

 ConnectionKeepAliveStrategy keepAliveStrategy = new DefaultConnectionKeepAliveStrategy() { @Override public long getKeepAliveDuration(final HttpResponse response, final HttpContext context) { long keepAlive = super.getKeepAliveDuration(response, context); if (keepAlive == -1) { keepAlive = 5000; } return keepAlive; } }; 

Shutdown policy

The main drawback of the classic blocking I / O model is that network sockets respond to I / O events only when I / O is blocked. When the connection is returned to the manager, it can be kept alive without monitoring the status of the socket and responding to any I / O events. If the connection is closed on the server side, then the client connection cannot detect changes in the connection state and disconnect the local socket in order to respond correctly.

HttpClient tries to fix this problem by testing if the connection is out of date, which is no longer valid because it is already closed on the server side before using the connection that made the HTTP request. Checking for an outdated connection is not 100% stable, but instead, it takes 10 to 30 milliseconds for each query execution. The only workable solution for the threaded socket model that does not include any free connection is to use a dedicated monitoring stream to restore the connection, which is considered expired due to prolonged inactivity. Flow monitoring can periodically call the ClientConnectionManager#closeExpiredConnections() method to close all expired connections and exit the closed connection of the connection pool. Alternatively, it can also call the ClientConnectionManager#closeIdleConnections() method to close all connections that have been idle for more than a certain period of time.

Link to the resource:

http://dev.dafan.info/detail/513285

Answer 2

A ConnectTimeout specifies the maximum latency of the other party’s response “yes, I'm here, let’s say” when creating a new connection ( ConnectTimeout ultimately calls socket.connect (address, timeout) . The timeout is usually less than a second, unless the other side is busy only accepting new incoming connections or you need to go through the big firewall of China. In the latter cases, it may be a minute (or more) before creating a new connection. If the connection is not established within ConnectTimeout , you will receive an error message (1).

setSocketTimeout eventually calls socket.setSoTimeout , which is explained in this answer .

ConnectionTimeToLive determines the maximum age of the connection (after which it will be closed), regardless of when the last connection was used. Typically, there is a “downtime timeout” for cleaning connections, i.e. You or the other side will close the connection that has not been used for a while. Typically, you close an idle connection before the other side does so to prevent errors. But there are two other cases that I can think of where the maximum age for connection is useful:

• Bad network components: consider yourself happy if you have not met them. Some bad routers, firewalls, proxies, etc. Just terminate (actively used) connections after something like 30 minutes. Since you and the other side may not even know that the connection has been deleted, you may get "connection reset" errors for some obvious reason in strange times.
• Cached metadata: most systems contain some connection metadata in some kind of cache. Some systems poorly manage this cache - the cache size only increases with the age of the connection.

A note on the implementation of ConnectionTimeToLive in Apache HttpClient 4.5.4: I think you should use the PoolingHttpClientConnectionManager for the parameter (ultimately it comes down to calling this isExpired method ). If you are not using this connection manager, check the option to make sure that it really works.

(1) An interesting comment from AJP on this related answer