You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by "KARR, DAVID (ATTSI)" <dk...@att.com> on 2010/08/02 17:48:00 UTC
Moving to MultiThreadedHttpConnectionManager, allowing unlimited connections?
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: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
RE: Moving to MultiThreadedHttpConnectionManager, allowing unlimited connections?
Posted by "KARR, DAVID (ATTSI)" <dk...@att.com>.
> -----Original Message-----
> From: Oleg Kalnichevski [mailto:olegk@apache.org]
> Sent: Tuesday, August 03, 2010 5:48 AM
> To: HttpClient User Discussion
> Subject: Re: Moving to MultiThreadedHttpConnectionManager, allowing
> unlimited connections?
>
> On Mon, 2010-08-02 at 08:48 -0700, KARR, DAVID (ATTSI) wrote:
> > Using HttpClient 3.0.1.
> >
>
> 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.
Glad to hear it. :) Using older versions isn't my choice. This is good ammunition.
Re: Moving to MultiThreadedHttpConnectionManager, allowing
unlimited connections?
Posted by Oleg Kalnichevski <ol...@apache.org>.
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: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org