DO NOT REPLY [Bug 23663] - Connections are not release when a recoverable exception occurs.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: MultiThreadedHttpConnectionManager question

Hi Andrea, The MultiThreadedHttpConnectionManager creates connections and keeps them open as long as it can. The number of connections kept open can be configured using setMaxConnectionsPerHost() and setMaxTotalConnections(). The issue of the sockets in the CLOSE_WAIT state seems to be a sid

DO NOT REPLY [Bug 23663] - Connections are not release when a recoverable exception occurs.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bu

Re: Is there still anything that blocks 2.0RC2 release?

Ortwin Glück wrote: Oleg Kalnichevski wrote: Are there any reasons for NOT automatically releasing connection? I can't think of any. Right. I think HttpClient should abstract the physical connections away from the user. So connection handling must be completely inside HttpClient. The only "ex

MultiThreadedHttpConnectionManager question

Hi everyone! I'd like to ask some question about http pool in commons-httpclient. As i read, MultiTrheadedHttpConnectionManager is the manger responsible for handling the connection in a multi-thread enviroment. I want to use this to create a private HttpClient property in a servlet class, so each

Re: [VOTE] 2.0 RC2 release

+1 Michael Becke wrote: I propose that we mark the latest code in CVS HTTPCLIENT_2_0_BRANCH as RC2 and proceed with a release. Please vote as follows: -- Vote: HttpClient 2.0 RC2 release [ ] +1 I am in favor of the re

Re: Is there still anything that blocks 2.0RC2 release?

Oleg Kalnichevski wrote: Are there any reasons for NOT automatically releasing connection? I can't think of any. Right. I think HttpClient should abstract the physical connections away from the user. So connection handling must be completely inside HttpClient. The only "exception" is that the us