Using HttpClient 3.0.1. In examining how to optimize my use of HttpClient in a multithreaded server, I realized that I'm creating a new HttpClient object for every connection, and using the default ConnectionManager (and using SSL for the connection). This means that it likely isn't going to be reusing connections. As a result, I'm now examining how (and whether) to reuse my HttpClient object and use the MultiThreadedHttpConnectionManager.
I've read through the "performance" page and the "threading guide", but I still have some concerns. First, I see that the MultiThreadedHttpConnectionManager has a notion of a "maximum" number of connections. I've never had to consider a limit before. I'd prefer not to have to consider any limit at all. I don't see a way to make it unlimited. This is my primary concern, except for any other issues that I'm not aware of. :) Our application connects to numerous services, but they're all served on two different (load-balanced) hosts. We could easily have many concurrent calls to different services (or the same service) at the same time, on different threads. Each particular service interface gets a different configured "read timeout", which we use for the socket timeout. In addition, we also allow each service interface to have a connection timeout value, which has been misunderstood in the past to be analogous to the read timeout. On each service call, we currently create a HttpClientParams object with the socket and connection timeout, then create the HttpClient object from that, and then create the PostMethod with the URI. I see that I can pass the HttpClientParams to the PostMethod instead of HttpClient, so that's ok. Setting the connection manager timeout is probably meaningless, so perhaps I'll deprecate that part, or even leave it there. I've always released the connection in the finally block that executes the method, so that's ok. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
