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]