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 Eugeny N Dzhurinsky <bo...@redwerk.com> on 2006/11/23 17:57:23 UTC
MultiThreadedHttpConnectionManager
Hello!
I have a question: my application consists of several tens of threads, which
are sharing same HttpClient instance. I was using
MultiThreadedHttpConnectionManager to get connections, but I found there are
too many cases when for some reasons hosts are reporting "connection timed
out" error, while they are working great. I tried to avoid such cases with
settin explicit socket factory, which uses JDK 1.4+ connect method with
timeout. That resolved many issues, but there are still cases when host
reports connect timed out, but works great itself.
Looks like the application creates too many sockets (as I wrote in some of my
previous e-mails), so probably I don't need that multithreaded connection
manager - but simple connection manager, which closes sockets after they are
used and HttpMethod.releaseConnection is called, rather than keeps this
connection for later usage?
If I write such connection manager, will that affect cookies and related
information for each host, which is being kept in the HttpClient somehow?
--
Eugene N Dzhurinsky
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: MultiThreadedHttpConnectionManager
Posted by Mark Claassen <mc...@ocie.net>.
I am not sure where you are at in the whole HttpClient process. When I
first tried this I had the same problem. If you are a novice user like me,
you might just be using the API incorrectly. It turns out that using
PostMethod.exec() (or whatever, ...I don't have the API in front of me)
solved the problem. Apparently, there is a lot of stuff that I was not
doing. (At first, I just trying to use the same coding methodology I used
when using the java.net.HttpURLConnection stuff.) Once I refactored my code
to follow the same structure as in the examples, it worked perfectly.
Mark
-----Original Message-----
From: Oleg Kalnichevski [mailto:olegk@apache.org]
Sent: Thursday, November 23, 2006 2:02 PM
To: HttpClient User Discussion
Subject: Re: MultiThreadedHttpConnectionManager
On Thu, 2006-11-23 at 18:57 +0200, Eugeny N Dzhurinsky wrote:
> Hello!
>
> I have a question: my application consists of several tens of threads,
> which are sharing same HttpClient instance. I was using
> MultiThreadedHttpConnectionManager to get connections, but I found
> there are too many cases when for some reasons hosts are reporting
> "connection timed out" error, while they are working great. I tried to
> avoid such cases with settin explicit socket factory, which uses JDK
> 1.4+ connect method with timeout. That resolved many issues, but there
> are still cases when host reports connect timed out, but works great
itself.
>
> Looks like the application creates too many sockets (as I wrote in
> some of my previous e-mails), so probably I don't need that
> multithreaded connection manager - but simple connection manager,
> which closes sockets after they are used and
> HttpMethod.releaseConnection is called, rather than keeps this connection
for later usage?
>
> If I write such connection manager, will that affect cookies and
> related information for each host, which is being kept in the HttpClient
somehow?
>
Eugeny,
I believe this problem can be resolved using the standard HttpClient API
without having to write a custom connection manager.
Standard HTTP connection managers keep connections alive for a good reason.
The use of persistent connections usually results in a noticeable
performance improvement. Generally persistent connections are a good thing.
It is, however, the responsibility of _your_ application to make sure
persistent connections get closed in an orderly manner if they are no longer
needed.
HttpConnectionManager interface provides #closeIdleConnections() method
intended to close connections that have been idle for a given period of
time. One is advised to call #closeIdleConnections() on a regular basis from
a dedicated observer thread to drop connections that have been idle for too
long. It is also possible to #closeIdleConnections() from the processing
thread when a unit of work has been completed and a long period of
inactivity is expected. Invoking #closeIdleConnections() with zero as a
parameter will effectively close all connections in the pool.
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: MultiThreadedHttpConnectionManager
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, 2006-11-23 at 18:57 +0200, Eugeny N Dzhurinsky wrote:
> Hello!
>
> I have a question: my application consists of several tens of threads, which
> are sharing same HttpClient instance. I was using
> MultiThreadedHttpConnectionManager to get connections, but I found there are
> too many cases when for some reasons hosts are reporting "connection timed
> out" error, while they are working great. I tried to avoid such cases with
> settin explicit socket factory, which uses JDK 1.4+ connect method with
> timeout. That resolved many issues, but there are still cases when host
> reports connect timed out, but works great itself.
>
> Looks like the application creates too many sockets (as I wrote in some of my
> previous e-mails), so probably I don't need that multithreaded connection
> manager - but simple connection manager, which closes sockets after they are
> used and HttpMethod.releaseConnection is called, rather than keeps this
> connection for later usage?
>
> If I write such connection manager, will that affect cookies and related
> information for each host, which is being kept in the HttpClient somehow?
>
Eugeny,
I believe this problem can be resolved using the standard HttpClient API
without having to write a custom connection manager.
Standard HTTP connection managers keep connections alive for a good
reason. The use of persistent connections usually results in a
noticeable performance improvement. Generally persistent connections are
a good thing. It is, however, the responsibility of _your_ application
to make sure persistent connections get closed in an orderly manner if
they are no longer needed.
HttpConnectionManager interface provides #closeIdleConnections() method
intended to close connections that have been idle for a given period of
time. One is advised to call #closeIdleConnections() on a regular basis
from a dedicated observer thread to drop connections that have been idle
for too long. It is also possible to #closeIdleConnections() from the
processing thread when a unit of work has been completed and a long
period of inactivity is expected. Invoking #closeIdleConnections() with
zero as a parameter will effectively close all connections in the pool.
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: MultiThreadedHttpConnectionManager
Posted by Roland Weber <ht...@dubioso.net>.
Hello Eugeny,
> Looks like the application creates too many sockets (as I wrote in some of my
> previous e-mails), so probably I don't need that multithreaded connection
> manager - but simple connection manager, which closes sockets after they are
> used and HttpMethod.releaseConnection is called, rather than keeps this
> connection for later usage?
"The" (our) SimpleConnectionManager does not close sockets, so I suggest
you look for a different name to avoid confusion.
> If I write such connection manager, will that affect cookies and related
> information for each host, which is being kept in the HttpClient somehow?
No, cookies are kept in an HttpState object. Closing the socket connection
after each request will only affect performance.
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org