Sync PoolingClientConnectionManager or not

Question

In my application, several IntentService connect / interact with the Tomcat server at random intervals depending on the 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 just fine, except that it gives connectTimeOut whenever two IntentService try to execute Http at the same time or when one connection is made and another connection is established.

One obvious code improvement is replacing the deprecated ThreadSafeClientConnManager with a PoolingClientConnectionManager.

Should I synchronize here -> public static synchronized HttpClient getHttpClient()

What error does Singleton call connectTimeOut?

Answer 1

Sync PoolingClientConnectionManager or not?

Yes and no. If you want getHttpClient() be single (IMO is a good idea), you should make it thread safe. This requires synchronized . Without synchronized two threads can simultaneously enter an if block (because customHttpClient == null is true for both threads) and create two instances.

But it’s better (faster) without synchronized create thread-safe singletones. For example, I like the Singleton Holder approach.

But no matter which singleton you use here, you should not receive connection timeouts. It should also work if you are using new HttpClient instances for each stream.

---

If a connection timeout occurs, one of your threads was unable to connect to the server for the time you set with HttpConnectionParams.setConnectionTimeout(params, 5000); = 5 seconds.

There may be several reasons for this. For example, if you are on a slow and unstable connection, this may take longer because it may happen that your connection is dead for several seconds. Or if your server cannot handle more connections, either because of the configuration (for example, limiting the connection to IP), or because the hardware cannot handle more, you can also see this problem. Basically, anything that prevents sending and receiving HttpClient packets to / from the server can cause this problem. Means that your problem is either with the device, or with the network or server.

I do not know your network setup, but you can try to increase the timeout and see if this has any effect. For example, AndroidHttpClient sets these timeouts to 60 seconds. This is much more than required if you are on a Wi-Fi network and have a stable connection, but it is good when the connection is really weak.

You can also check if other settings that AndroidHttpClient help AndroidHttpClient are AndroidHttpClient .

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 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 is located, you can look in your server connection logs and check if the device is trying to initiate a connection, and if so, are there any reasons why the connection has not been established. If you do not see connection attempts when a timeout occurs, it is more likely a device or network problem.

If you have access to the network the device is connected to (= WiFi), you can check the network traffic, for example. Wireshark for reasons related to connection attempts. You can see this if the device sends a connection request or not.

Last but not least, it may be caused by some of your codes. If you cannot find another solution, try implementing it with the HttpURLConnection and see if that helps.