Hi Ash,

> I have set it to 200 total + 50 per host (there are only 2 possible
> hosts)

Ok, so there should be no more than 100 connections open.

> public class HttpClientSingleton {
>       
>       private static HttpClient client = null;
>       
>       public static HttpClient getInstance(){
>               
>               if (null == client){
>                       MultiThreadedHttpConnectionManager
> connectionManager = new MultiThreadedHttpConnectionManager();
>       
> connectionManager.getParams().setMaxConnectionsPerHost(HostConfiguration
> .ANY_HOST_CONFIGURATION, 50);
>       
> connectionManager.getParams().setMaxTotalConnections(200);
>               client = new HttpClient(connectionManager);
>               }
>               
>               return client;
>       }
> }
> 
> Does that look sensible?

I have two concerns:

1. There is no synchronization, so more than one instance might be
   created. Shouldn't matter much, because the inactive ones will
   not be used to open connections. However, they might not be GCed
   because of a background thread that cleans up stale connections.

2. Is it possible that the class is loaded multiple times in different
   classloaders? Or is reloaded frequently? Not likely, I admit.

> I am using Apache Client for the SSL / https, is it possible to use a
> different implementation of SSL in the client itself?

"Apache Client"? I've heard about Sun JSSE, IBM JSSE and some others,
but never about "Apache Client". Here are some alternatives mentioned
at some time or other on one of the mailing lists:
http://wiki.apache.org/jakarta-httpclient/AlternativeJSSE

> Always a possibility, but the other code that is used (non-proxy stuff)
> has been used on live successfully for 6 months or so.

I thought about the part of your new code that connects to the client,
or writes log files, or whatever. There might also be a leak of (socket)
connections if the SSL implementation (JSSE) misbehaves. Timeouts in
combination with SSL sockets are also a potential area of trouble.

When digging through the mailing list archives, you'll also find
reports of sockets being left in a CLOSE_WAIT state (IIRC). That has
usually to do with bugs in the JDK or OS. Don't know whether that
would match with your observations.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to