On Aug 16, 2009, at 7:45pm, yccheok wrote:
Hi Ken,
Can you elaborate more on "and if these exceeds a (configurable)
limit,
you'll get an exception."?
At least in HttpClient 4.0, if you make a request, and there's no free
connection in the pool, then your request blocks until a connection
becomes available (because some other request completed). If too much
time passes with the request blocked, the blocked request throws an
exception.
-- Ken
I am not quite understand.
Ken Krugler wrote:
Hi Yan Cheng,
I haven't used HttpClient 3.x for a while - switched to 4.0 and
haven't looked back.
But in general method A is going to work better. You can configure
the
MultiThreadedHttpConnectionManager with a maximum number of threads -
e.g. you could pick a number equal to the max # of threads that you
know will be using it. If it's configured with less than the max
number of threads, then some of your connection requests will block
until a free connection becomes available - and if these exceeds a
(configurable) limit, you'll get an exception.
In extreme situations I've run with up to 1000 threads and one
connection manager, so I don't think you'll hit any limits there.
-- Ken
On Aug 16, 2009, at 6:11am, Yan Cheng Cheok wrote:
Hi all,
All the while, I am using HttpClient in multithreaded environment.
For every threads, when they initiate a connection, they will create
a complete new HttpClient instance.
Recently, I discover, by using this approach, it can cause the user
is having too many port being opened, and most of the connections
are in TIME_WAIT state.
http://www.opensubscriber.com/message/commons-httpclient-...@jakarta.apache.org/86045.html
Hence, instead of per thread doing :
HttpClient c = new HttpClient();
try {
c.executeMethod(method);
}
catch(...) {
}
finally {
method.releaseConnection();
}
We plan to have :
[METHOD A]
// global_c is initialized once through
// HttpClient global_c = new HttpClient(new
MultiThreadedHttpConnectionManager());
try {
global_c.executeMethod(method);
}
catch(...) {
}
finally {
method.releaseConnection();
}
In normal situation, global_c will be accessed by 50++ threads
concurrently. I was wondering, whether this will occur any
performance issue? Is MultiThreadedHttpConnectionManager using lock-
free mechanism to implement its thread safe policy?
It is possible if 10 threads are using global_c, will the other 40
threads being locked?
Or will it better if in every threads, I create a instance for every
HttpClient, but release the connection manager explicitly.
[METHOD B]
HttpClient c = new HttpClient();
try {
c.executeMethod(method);
}
catch(...) {
}
finally {
method.releaseConnection();
c.getHttpConnectionManager().shutdown();
}
Is c.getHttpConnectionManager().shutdown() suffer performance
issues?
May I know which method (A or B) is better, for application using
50+
+ threads?
I am using HttpClient 3.1
Thanks and Regards
Yan Cheng Cheok
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
For additional commands, e-mail: httpclient-users-h...@hc.apache.org