1
votes

Apache HttpClient allows to configure two timeouts: ConnectionTimeout and SoTimeout

This is how people typically create a general purpose HttpClient instance:

PoolingClientConnectionManager conman = new PoolingClientConnectionManager();
conman.setMaxTotal(200);
conman.setDefaultMaxPerRoute(100);
HttpClient httpClient = new DefaultHttpClient(conman);
HttpConnectionParams.setConnectionTimeout(httpClient.getParams(), 1000);
HttpConnectionParams.setSoTimeout(httpClient.getParams(), 1000);

The ConnectionTimeout param is tricky, it covers two scenarious:

  • HttpClient may throw org.apache.http.conn.ConnectTimeoutException: Connect to example.com timed out - if it wasn't able to establish an underlying TCP connection

  • Also it may throw org.apache.http.conn.ConnectionPoolTimeoutException: Timeout waiting for connection from pool - when the connection pool is full and it wasn't able to get a new connection from pool within this period of time

I have two questions around this:

1) Is there a reason why these two actually different timeouts were combined under single ConnectionTimeout param.
There is no way for example to wait for available connection from pool for 10sec, but keep socket-connection-timeout to 1sec

2) What are recommended values for ConnectionTimeout and SoTimeout for general purpose scenario?

1
DefaultHttpClient is deprecated now, and HttpClient 4.5 has 3 methods to configure timeouts: setConnectTimeout, setSocketTimeout, setConnectionRequestTimeout - Vladimir Sorokin

1 Answers

0
votes
  1. Because that's the way they designed it. Knowing why won't change your life.
  2. 10s is enough for a connect timeout. A read timeout value depends entirely on the expected service time. You need to set it high enough to allow for load spikes but low enough to be useful. You could set it to twice the expected service time, or two or three standard deviations above it if you have that kind of statistical data on it.