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.
Thanks,
Mike
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
