I am not sure where you are at in the whole HttpClient process. When I first tried this I had the same problem. If you are a novice user like me, you might just be using the API incorrectly. It turns out that using PostMethod.exec() (or whatever, ...I don't have the API in front of me) solved the problem. Apparently, there is a lot of stuff that I was not doing. (At first, I just trying to use the same coding methodology I used when using the java.net.HttpURLConnection stuff.) Once I refactored my code to follow the same structure as in the examples, it worked perfectly.
Mark -----Original Message----- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Thursday, November 23, 2006 2:02 PM To: HttpClient User Discussion Subject: Re: MultiThreadedHttpConnectionManager On Thu, 2006-11-23 at 18:57 +0200, Eugeny N Dzhurinsky wrote: > Hello! > > I have a question: my application consists of several tens of threads, > which are sharing same HttpClient instance. I was using > MultiThreadedHttpConnectionManager to get connections, but I found > there are too many cases when for some reasons hosts are reporting > "connection timed out" error, while they are working great. I tried to > avoid such cases with settin explicit socket factory, which uses JDK > 1.4+ connect method with timeout. That resolved many issues, but there > are still cases when host reports connect timed out, but works great itself. > > Looks like the application creates too many sockets (as I wrote in > some of my previous e-mails), so probably I don't need that > multithreaded connection manager - but simple connection manager, > which closes sockets after they are used and > HttpMethod.releaseConnection is called, rather than keeps this connection for later usage? > > If I write such connection manager, will that affect cookies and > related information for each host, which is being kept in the HttpClient somehow? > Eugeny, I believe this problem can be resolved using the standard HttpClient API without having to write a custom connection manager. Standard HTTP connection managers keep connections alive for a good reason. The use of persistent connections usually results in a noticeable performance improvement. Generally persistent connections are a good thing. It is, however, the responsibility of _your_ application to make sure persistent connections get closed in an orderly manner if they are no longer needed. HttpConnectionManager interface provides #closeIdleConnections() method intended to close connections that have been idle for a given period of time. One is advised to call #closeIdleConnections() on a regular basis from a dedicated observer thread to drop connections that have been idle for too long. It is also possible to #closeIdleConnections() from the processing thread when a unit of work has been completed and a long period of inactivity is expected. Invoking #closeIdleConnections() with zero as a parameter will effectively close all connections in the pool. Hope this helps Oleg --------------------------------------------------------------------- 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]
