On Mon, 2010-08-02 at 08:48 -0700, KARR, DAVID (ATTSI) wrote: > 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. >
Reuse of HttpClient is *strongly* recommended. > 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. :) > Set limits to Integer.MAX and live happily ever after. Make sure to increase the max per host (route) setting, not just the total max > 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. > Do consider upgrading to HttpClient 4.0.x at some point, though. 3.1 is pretty much end of life. I will soon stop answering any questions about 3.x API. I really mean it. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
