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 connection 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 -----Original Message----- From: Andrea Fabris [mailto:[EMAIL PROTECTED] 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: logging). 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. Regards Andrea Fabris Errore Apertura DB --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] *************************************************************************************************** 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]
