In my app more than one IntentService connect/communicate with a Tomcat server at random intervals depending on user interaction with the application.
I am using the following Singleton for Http
public class CustomHttpClient {
private static HttpClient customHttpClient;
/** A private Constructor prevents instantiation */
private CustomHttpClient() {
}
public static synchronized HttpClient getHttpClient() {
if (customHttpClient == null) {
HttpParams params = new BasicHttpParams();
HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
HttpProtocolParams.setContentCharset(params, HTTP.DEFAULT_CONTENT_CHARSET);
HttpProtocolParams.setUseExpectContinue(params, true);
HttpProtocolParams.setUserAgent(params,"Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83)" +
" AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1");
ConnManagerParams.setTimeout(params, 1000);
HttpConnectionParams.setConnectionTimeout(params, 5000);
HttpConnectionParams.setSoTimeout(params, 10000);
SchemeRegistry schReg = new SchemeRegistry();
schReg.register(new Scheme("http", PlainSocketFactory.getSocketFactory(), 80));
schReg.register(new Scheme("https", SSLSocketFactory.getSocketFactory(), 443));
ClientConnectionManager conMgr = new ThreadSafeClientConnManager(params,schReg);
customHttpClient = new DefaultHttpClient(conMgr, params);
}
return customHttpClient;
}
public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}
}
The class works fine except it gives connectTimeOut whenever two IntentService try to Http at the same time or when one connection is in progress and another connection is established.
One obvious improvement in the code is to replace deprecated ThreadSafeClientConnManager with PoolingClientConnectionManager.
Should I synchronize here -> public static synchronized HttpClient getHttpClient()
What error in the Singleton is causing the connectTimeOut?
Synchronize the PoolingClientConnectionManager or not?
Yes and no. If you want getHttpClient() to be a singleton (IMO a good idea) you have to make it thread safe. That requires the synchronized. Without synchronized two thread can enter the if block at the same time (because customHttpClient == null is true for both threads) and create two instances.
But there are better (as in faster) ways without synchronized to create thread-safe singletons. I like the Singleton Holder approach for example.
But regardless of the singleton you use here you should not get connection timeouts. It should also work if you use new HttpClient instances for each thread.
If a connection timeout happens then one of your threads did not manage to connect to the server within the time limit you have set with HttpConnectionParams.setConnectionTimeout(params, 5000); = 5 seconds.
That can have several reasons. For example if you are on a slow & instable connection it may take longer because it can happen that your connection is dead for several seconds. Or if your server can't handle more connections either due to the configuration (e.g. a connection limit per IP) or because the hardware can't handle more you can see this problem too. Basically anything that prevents the HttpClient to send and receive packets to / from the server can trigger that problem. Means your problem is either on the device or in the network or on the server.
I don't know your network setup but you could try to increase the timeout and see if that has any effect. The AndroidHttpClient for example sets those timeouts to 60 seconds. That is much more than required if you are on WiFi and have a stable connection but is good when the connection is really weak.
You could also check if the other settings that AndroidHttpClient applies help.
Setup of AndroidHttpClient below
// Default connection and socket timeout of 60 seconds. Tweak to taste.
private static final int SOCKET_OPERATION_TIMEOUT = 60 * 1000;
// ---------------------------------------------------------------------- //
HttpParams params = new BasicHttpParams();
// Turn off stale checking. Our connections break all the time anyway,
// and it's not worth it to pay the penalty of checking every time.
HttpConnectionParams.setStaleCheckingEnabled(params, false);
HttpConnectionParams.setConnectionTimeout(params, SOCKET_OPERATION_TIMEOUT);
HttpConnectionParams.setSoTimeout(params, SOCKET_OPERATION_TIMEOUT);
HttpConnectionParams.setSocketBufferSize(params, 8192);
// Don't handle redirects -- return them to the caller. Our code
// often wants to re-POST after a redirect, which we must do ourselves.
HttpClientParams.setRedirecting(params, false);
// Use a session cache for SSL sockets
SSLSessionCache sessionCache = context == null ? null : new SSLSessionCache(context);
// Set the specified user agent and register standard protocols.
HttpProtocolParams.setUserAgent(params, userAgent);
SchemeRegistry schemeRegistry = new SchemeRegistry();
schemeRegistry.register(new Scheme("http",
PlainSocketFactory.getSocketFactory(), 80));
schemeRegistry.register(new Scheme("https",
SSLCertificateSocketFactory.getHttpSocketFactory(
SOCKET_OPERATION_TIMEOUT, sessionCache), 443));
ClientConnectionManager manager =
new ThreadSafeClientConnManager(params, schemeRegistry);
return new DefaultHttpClient(manager, params);
To determine where your problem lies you could have a look into your server connection logs and check if the device tries to initiate a connection and if so if there are reasons why the connection is not established. If you don't see any connection attempts when the timeout happens it is more likely a device or network problem.
If you have access to the network the device is connected to (=WiFi) you could check the network traffic with e.g. Wireshark for reasons the connection attempt times out. You can see there if the device sends a connection request or not.
And last but not least it can be caused by some of your code. If you find no other solution try to implement it with HttpURLConnection and see if that helps.