The deprecated or 3.x way of setting the timeout.

DefaultHttpClient httpClient = ...; HttpParams httpParams = httpClient.getParams(); httpParams.setParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, 1000L); httpParams.setParameter(CoreConnectionPNames.SO_TIMEOUT, 1000L); httpParams.setParameter(ClientPNames.CONN_MANAGER_TIMEOUT, 1000L);

The right 4.x way aka the builder way

public RequestConfig requestConfigWithTimeout(int timeoutInMilliseconds) { return RequestConfig.copy(RequestConfig.DEFAULT) .setSocketTimeout(timeoutInMilliseconds) .setConnectTimeout(timeoutInMilliseconds) .setConnectionRequestTimeout(timeoutInMilliseconds) .build(); }

The meaning of the parameters

Socket Timeout - this is the time of inactivity to wait for packets to arrive

- this is the time of inactivity to wait for packets to arrive Connection Timeout - the time to establish a connection with the remote host

- the time to establish a connection with the remote host Connection Manager Timeout - the time to fetch a connection from the connection pool

More info

HttpClient is one of the most versatile Java libraries. Unfortunately, it comes with a lot of configuration options that may be way too cryptic or difficult. While the API for 4.x series has been significantly improved there are still some sharp edges.This is done using params. Note that this is still 4.x code but a deprecated one.Now the part httpClient.getParams() is deprecated since obviously this is a nasty API. You need to keep track of parameters with Enums/constants and their type as well.HttpClient 4 is full of builder for everything. While I often love the Builder patterns in some cases the testing part is really difficult but I guess it is always a tradeoff. This would be the "right way".Notice that we are actually setting 3 different timeouts.The third one costed me dearly, it wasn't until the client was under a high load that issues started happening. The connection pool I was using had 10 connections per route limitation set and the scenario was quite common. As you can see these settings do not provide a mechanism for making an N millisecond hard timeout.If we were to setup the timeout to 10 seconds on each of this we could end up with a request that lasts 9(sec to get a connection) + 9( sec to open connection ) + 9( sec of inactivity ) = 27 sec.A bug when setting the ConnectionRequestTimeout The RequestConfig Javadoc Apache HttpClient examples