You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Andre John Mas <am...@expedia.com> on 2004/03/19 21:11:48 UTC
Multithreaded Connection manager question and 400+ servers
Hi,
At the company I work for we are developing a middleware application
that routes SOAP messages from one party too another, using HTTP. I
have suggested that we use the MultithreadedConnectionManager, though
at the moment there is some reluctence. The issue seems to be because
we are potentially connecting to 400+ different servers. The danger of
keeping a connection open could mean that there are no connections left
to connect to another server to send the messages. There are also
worries that some of the parties we connect to have basic HTTP
implementations (there are a lot of homebrew solutions in C/C++) and
therefore don't handle more than one query/answer on the same connection.
I should mention that at the moment we create a new HTTPClient for every
connection and the client is not reused across any threads.
Because of the shear volume of traffic we are likely to be handling I am
wanting to find ways of optimizing the use of every API we use, while
not breaking anything.
Has anyone used HTTPClient in this sort of situation? What is the best
way to go about using HTTPClient for this? Is there anything else I
should know?
regards
Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: Multithreaded Connection manager question and 400+ servers
Posted by Michael Becke <be...@u.washington.edu>.
Hi Andre,
I have not used HttpClient in a situation as you describe, but I have a
few suggestions.
- I am not sure the multi-threaded connection manager will be much use
for you. If you will be regularly connecting to 400+ different
servers, there will be little cause for reusing connections. This will
depend on how temporally varied the series of request will be, but I
don't imagine you want a connection pool holding on to 400+
connections. It may be good to test out a few scenarios to be sure.
If so you will definitely want to play with setMaxConnectionsPerHost()
and setMaxTotalConnections() in MultiThreadedHttpConnectionManager().
- You should definitely be reusing instances of HttpClient. By
default each HttpClient instance creates a SimpleHttpConnectionManager
which holds one connection. It is very likely that dropping these
instances of HttpClient is resulting in leaked connections/sockets. In
your situation a single HttpClient/SimpleHttpConnectionManager instance
per thread my be the best solution. You may also want to consider
implementing a custom HttpConnectionManager if you want finer control
over connections/sockets.
Mike
On Mar 19, 2004, at 3:11 PM, Andre John Mas wrote:
> Hi,
>
> At the company I work for we are developing a middleware application
> that routes SOAP messages from one party too another, using HTTP. I
> have suggested that we use the MultithreadedConnectionManager, though
> at the moment there is some reluctence. The issue seems to be because
> we are potentially connecting to 400+ different servers. The danger of
> keeping a connection open could mean that there are no connections left
> to connect to another server to send the messages. There are also
> worries that some of the parties we connect to have basic HTTP
> implementations (there are a lot of homebrew solutions in C/C++) and
> therefore don't handle more than one query/answer on the same
> connection.
>
> I should mention that at the moment we create a new HTTPClient for
> every
> connection and the client is not reused across any threads.
>
> Because of the shear volume of traffic we are likely to be handling I
> am
> wanting to find ways of optimizing the use of every API we use, while
> not breaking anything.
>
> Has anyone used HTTPClient in this sort of situation? What is the best
> way to go about using HTTPClient for this? Is there anything else I
> should know?
>
> regards
>
> Andre
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
Re: Multithreaded Connection manager question and 400+ servers
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Andre,
you should try to get some real-life data to decide on
connection management. Like a trace on how many
connections are made to which hosts in what frequency.
Then you can verify whether the frequently used hosts
support connection keep-alive or not.
I agree with Michael's assessment that a single connection
per thread is the best way to go in this situation, unless you
are sure there is some gain in connection reuse.
By implementing a custom connection manager, you
have full control over how long connections are kept
alive, so you can manage that risk.
Servers that cannot handle more than one request per
connection are supposed to send "connection: close"
headers back, and/or use HTTP 1.0. Connections will
only be reused for servers that clearly indicate by the
HTTP protocol version and connection headers that
they are capable of handling another request.
cheers,
Roland
Andre John Mas <am...@expedia.com>
19.03.2004 21:11
Please respond to "Commons HttpClient Project"
To: "'Commons HttpClient Project'"
<co...@jakarta.apache.org>
cc:
Subject: Multithreaded Connection manager question and
400+ servers
Hi,
At the company I work for we are developing a middleware application
that routes SOAP messages from one party too another, using HTTP. I
have suggested that we use the MultithreadedConnectionManager, though
at the moment there is some reluctence. The issue seems to be because
we are potentially connecting to 400+ different servers. The danger of
keeping a connection open could mean that there are no connections left
to connect to another server to send the messages. There are also
worries that some of the parties we connect to have basic HTTP
implementations (there are a lot of homebrew solutions in C/C++) and
therefore don't handle more than one query/answer on the same connection.
I should mention that at the moment we create a new HTTPClient for every
connection and the client is not reused across any threads.
Because of the shear volume of traffic we are likely to be handling I am
wanting to find ways of optimizing the use of every API we use, while
not breaking anything.
Has anyone used HTTPClient in this sort of situation? What is the best
way to go about using HTTPClient for this? Is there anything else I
should know?
regards
Andre
---------------------------------------------------------------------
To unsubscribe, e-mail:
commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail:
commons-httpclient-dev-help@jakarta.apache.org