hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: MultiThreadedConnectionManager based on commons pool
Date Fri, 07 May 2004 03:59:33 GMT
Hi Andrea,

I would just like to echo some of Oleg's sentiments.

Thank you for your interest in HttpClient.  We are glad you have found  
it useful.

I agree with Oleg that we are not ready to add a new dependency on  
commons-pool.  On the other hand, we are also certainly interested in  
improving the MultiThreadedHttpConnectionManager.  Please let us know  
if you are experiencing any problems in particular, or if there is  
anything that you would like to have added.



On May 6, 2004, at 12:21 PM, Kalnichevski, Oleg wrote:

> Hi Andrea
> I (all of us, I suppose) are very glad that you find HttpClient useful.
> The commons-pool is a great and well tested library by itself. No  
> discussion about that. However, we should be very selective about  
> external dependencies. This issue would not be taken lightly. There  
> are enough folks out there (me included) who dislike/do not use  
> otherwise cool libraries with lots of external dependencies.
> Per default HttpClient uses single-connection connection manager  
> version and that is not likely to change in the foreseeable future.  
> Therefore I _personally_ tend to see commons-pool dependency as  
> unjustified. This said, we'd be glad to have your code included into  
> HttpClient 'contrib' package of optional components. Besides, we see  
> HttpClient in the future evolve from a client-side HTTP agent library  
> to a platform agnostic toolkit with a highly modular architecture,  
> which can be used to rapidly assemble HTTP agents, crawlers, proxy and  
> light-weight embeddable servers. At that point the decision about  
> dependency on commons-pool could be revisited.
> Is there anything you particularly dislike about the multi-threaded  
> connection manager, besides idle connections issue (which has been  
> resolved, and solved well, at least IMHO)? Please let us know. We'll  
> do try to address your concerns.
> Please also consider signing the Apache CLA  
> <http://www.apache.org/licenses/#clas>. The Project Management  
> Committee tends to be MUCH, MUCH more strict about accepting code  
> contributions these days, especially if you would like to be mentioned  
> as the author of the code you contribute
> Cheers,
> Oleg
> -----Original Message-----
> From: Andrea Fabris [mailto:cavaliereoscuro@email.it]
> Sent: Thursday, May 06, 2004 15:11
> To: Commons HttpClient Project
> Subject: MultiThreadedConnectionManager based on commons pool
> Hello Everybody!
> I'm Andrea from italy, and i'm very interested about the jakarta  
> httpclient.
> I tried it and i find it very easy to use, but i found (i wrote about  
> it
> some time ago) a bug in the multithredconnectionmanger.
> It seems that the opened connections are tested for closure only when
> they ahve to be given back from the pool to the client. In this way,
> after some time where the connections are not used, the connections are
> still open but the are in CLOSE_WAIT state: they are shut down when a
> client request for a new connection form the pool, but the pool finds
> the old conenction in a "CLOSE_WAIT" state, so it shuts down the
> conenction and creates a new one.
> Now, int this manner there could be a wate of resources, if nobody uses
> connections for a long time.
> I have seen that something has been done (in cvs) about auto closing
> idle connection, but i still think that the multithreaded connection
> manager needs a reimplementation.
> I think that could be a great idea to reimplement the manager using
> commons pool as a base.
> Simply, the manager has to trak a list of open pools based on
> GenericObjectPool: every pool in the manager (one for each host) must  
> be
> created using a factory that manages the connection life-cycle in the
> pool (in the common pool framework).
> I attach the code i've written, so you can take a look at it.
> Regards
> Andrea Fabris
> Errore Apertura DB
> *********************************************************************** 
> ****************************
> 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

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