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 10:53:34 GMT


Both 2.0 & CVS HEAD nightlies are available <http://jakarta.apache.org/commons/httpclient/downloads.html>.

This may sound a bit harsh, but I _personally_ do not see 2.0 API worthwhile of any further
development. As useful as it is HttpClient 2.0 API is fundamentally flawed in many ways. HttpClient
3.0 will resolve many of the known problems <http://cvs.apache.org/viewcvs.cgi/jakarta-commons/httpclient/release_notes.txt?rev=1.21&view=markup>
and will render 2.0 completely obsolete. Again, this is just my personal (humble) opinion.
As long as there's substantial interest in HttpClient 2.0, it will be supported. However,
I do think all new development should take place in CVS HEAD.


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

On 07/05/2004 10.38, Kalnichevski, Oleg wrote:

> Andrea,
> 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 con
nection monitor per default is to keep HttpClient usable in an EJB container. The EJB spec
requires that enterprise beans do no explicit thread management.
> 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.
> Oleg

Well, i thought the patch was for 2.0 branch, not 3.0!!! (i have to
admit that i gave only a fast look at the bugzilla reports on the list,
'cause i had a lot of work to do.. ;-) )
In fact i developed the code from the official 2.0 code!

However, i'll try to download the source from cvs, and compile it.. i
think that the nightly builds are from 2.0 branch, or not?

By the way, if you need further information about my code, feel free to ask

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