On Mon, May 30, 2005 at 10:51:15AM -0500, The Book Grove wrote: > Oleg, > > Requested information is as follows: > > (1) HttpClient 3.0 rc2 > (2) JRE 5.0 > (3) Windows XP Professional
Eeeehhhhh... > (4) SimpleHttpConnectionManager > (5) N/A > > Using the SimpleConnectionManager, is there a way to configure it so > that it will reuse a single socket per request, given that This is precisely what SimpleHttpConnectionManager does. It uses a single connection and keeps it alive as long as it can be reused. http://jakarta.apache.org/commons/httpclient/3.0/xref/org/apache/commons/httpclient/SimpleHttpConnectionManager.html > HttpMethod#releaseConnection, or force it to be dropped/closed or at > least in CLOSE_WAIT state (i've forgotten the exact phrase for sockets > in this state). Feel free to extend SimpleConnectionManager, override the releaseConnection method and close the connection prior to calling super#releaseConnection. However, I beleive the problem has nothing to do with the SimpleConnectionManager, rather with your OS/JRE combo > > Note: I've messed around with the MultiThreadedHttpConnectionManager > and didn't know exactly all of the configurations that could be set > with it, or if I even needed to be using it for my problems. Also, > I've seen in previous mailing archives code like > "HttpConnectionManager.getParams()". I've been looking in the JavaDocs > and at Jakarta Common's HttpClient site to learn how to use these > tools, and haven't found yet where getParams() comes from. Make sure you are looking at the javadocs for HttpClient 3.0 Try running your test app in Java 1.4.2 and see if you observe similar problem(s) Oleg > > Thanks in advance for your assistance. > > -Bailey- > > On 5/30/05, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote: > > Bailey, > > > > First of all, HttpMethod#releaseConnection does not necessarily close > > the underlying socket. If the connection can be reused, it will be kept > > alive indefinitely until closed either on the server or on the client > > side. > > > > Depending on the connection manager used and its configuration it > > is entirely possible that thousands of connections will end up in the > > LISTENING state, if no provisions have been made to evict connections > > from the connection pool. > > > > (1) which version of HttpClient are you using? > > (2) which JRE version? > > (3) which platform/OS? > > (4) which connection manager? > > (5) if you are using a pooling connection manager such as > > MultiThreadedHttpConnectionManager, what are connection pool settings? > > > > Oleg > > > > On Sun, May 29, 2005 at 07:05:28PM -0500, The Book Grove wrote: > > > I've written many programs and methods using HttpClient, and have > > > noticed that if I leave them running long enough, I will eventually > > > get JVM BindExceptions. Then I use "netstat -a" to look at the > > > thousands of sockets in the LISTENING state. I wrote a short little > > > program to produce the same socket problems. Below is a summary: > > > > > > HttpClient httpClient = new HttpClient(); > > > while(loop this 100,000 times) > > > { > > > Protocol protocol = new Protocol("https", new > > > EasySSLProtocolSocketFactory(), 443); > > > httpClient.getHostConfiguration().setHost("www.foobar.com", 80, "http"); > > > GetMethod getMethod = new GetMethod("/foobar.html"); > > > httpClient.executeMethod(getMethod); > > > //load response into linked list with BufferedReader, then close > > > reader when done > > > httpClient.releaseConnection(); > > > } > > > > > > Normally the releaseConnection() should clean up all resources, > > > correct? I don't think that this would be a problem if I could get the > > > sockets in a TIME_WAIT state (or whatever it's called). But since it > > > is in LISTENING state, nothing is done to regain them, not by Garbage > > > Collector and not by Operating System. > > > > > > Note: This is when running the test program in DOS using .bat files to > > > set classpaths and run the .class file. When using NetBeans, the > > > sockets are in "ESTABLISHED" state, but eventually I get the same > > > complaint about the sockets. > > > > > > Thanks in advance for your time and consideration. > > > > > > -Bailey- > > > > > > --------------------------------------------------------------------- > > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
