hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kalnichevski, Oleg" <oleg.kalnichev...@bearingpoint.com>
Subject RE: MultiThreadedConnectionManager based on commons pool
Date Fri, 07 May 2004 08:38:29 GMT


New HttpClient 3.0 API has not been properly documented yet (documentation and test case coverage
will become a top priority right after the 3.0-alpha1 release). The idle connection management
with the multi-threaded connection manager does take a little bit of explaining. Per default
the connection manager does not attempt to close idle connections as before. It simply provides
the user with the means to handle idle connections the way the user sees fit. There's a new
method in the HttpConnectionManager interface called #closeIdleConnections(long) intended
to advise the connection manager to drop those connections that have been idle for the specified
period of time. This method can be invoked either from the main communication thread during
a period of inactivity or from a dedicated  monitor thread on a regular basis. The helper
class IdleConnectionTimeoutThread can be used to easily set up a simple idle connection monitor.
The reason for not running a dedicated idle connection monitor per default is to keep HttpClient
usable in an EJB container. The EJB spec requires that enterprise beans do no explicit thread

Give the new features another shot. They may still prove not that bad

I just had the first cursory look at your commons-pool based implementation. It looks very
promising but the code currently requires a few tweaks to be compatible with 3.0 API.


-----Original Message-----
From: Andrea Fabris [mailto:cavaliereoscuro@email.it]
Sent: Friday, May 07, 2004 10:08
To: Commons HttpClient Project
Subject: Re: MultiThreadedConnectionManager based on commons pool

Thanks for your feedback!

Now i'll explain my thoughts about multithreaded manager.

The biggest problem tha manger has, is about the idle connection status:
for a long time now, as stated by a lot of people, idle connections
where not handled well, because they remain in CLOSE_WAIT status when
returned from the client to the pool until some client requests them back.
This is a waste of resources.
Now, after i noticed the bugzilla 25372 (is it closed, right now? I have
some problems accessing CVS...), i downloaded the latest nigthly build
and made a few test, but i discovered that the problem remains.
So i thought it would be easier to change the logic of the manager and
to base it on a pool library that is known to work.

However, i see your point of view: it would be desiderable to limit the
httpclient dependencies only to those libraries that are a must (eg:

By the way, as stated by oleg, i'm goig to sign the Apache CLA and
document better the code i attached in my prevoius mail, hoping that
this code could be useful in the contrib branch.

Andrea Fabris
Errore Apertura DB

To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

The information in this email is confidential and may be legally privileged.  Access to this
email by anyone other than the intended addressee is unauthorized.  If you are not the intended
recipient of this message, any review, disclosure, copying, distribution, retention, or any
action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. 
If you are not the intended recipient, please reply to or forward a copy of this message to
the sender and delete the message, any attachments, and any copies thereof from your system.

To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

View raw message