Pankaj, Okay, I may not be correct here and there actually is something you can do:
Please note that the MultiThreadedConnectionManager has no active eviction. The pool may fill with stale connections, and depending on your workload the pool may never have to evict them (with deleteConnection). You can create an eviction thread which periodically (every 5 seconds for instance) calls closeIdleConnections(). This should prevent the pool from filling with stale connections. As this topic arises every couple of months, and the web is full of problem reports about CLOSE_WAIT, I think we should add this to the documentation. Odi Pankaj Arora wrote: > Hi, > > I am using Http Commons to implement my http client and observe that > after running the client for large number of request connections are > left in close_wait stage. I searched through archives and noticed that > following were suggested: > > > > 1. Reuse instances of HttpClient or the associated > HttpConnectionManager, this may have threading implications. > > > I do that. > > 2. Do closeidleConnections(long timeout) or customIdleConnectionTimeout > thread > > I do closeIdleConnections(20*1000). Please do tell if anything else > needs to be done for this solution. > > 3. Add a "Connection: close" and/or "Proxy-Connection: close" header to > > all methods. This should work in most cases, assuming that the server > echoes the header in the response. > > > I don't want to do this as can't take the performance hit. > > > Is there any other way or do I need to do anything else in first 2 > solutions so that it works for me. > > I am using a Jetty based server for the response side. > > Thanks, > Pankaj Arora > > > > > > -- [web] http://www.odi.ch/ [blog] http://www.odi.ch/weblog/ [pgp] key 0x81CF3416 finger print F2B1 B21F F056 D53E 5D79 A5AF 02BE 70F5 81CF 3416 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
