Version: CVS: 23-Aug-2002, 19:15

JVM version:
  java version "1.4.0_01"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
  Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

My test script uses:
  - 100 threads 
  - 3 loops
  - 1 HTTP request per loop

I get many instances of the following exception.  Not on the
first test run, but about the fifth.  Once it starts, it keeps
happening; I have to restart JMeter.

java.net.SocketException: Too many open files
        at java.net.Socket.createImpl(Socket.java:312)
        at java.net.Socket.connect(Socket.java:423)
        at java.net.Socket.connect(Socket.java:375)
        at sun.net.NetworkClient.doConnect(NetworkClient.java:139)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:366)
        at sun.net.www.http.HttpClient.openServer(HttpClient.java:582)
        at sun.net.www.http.HttpClient.<init>(HttpClient.java:292)
        at sun.net.www.http.HttpClient.<init>(HttpClient.java:253)
        at sun.net.www.http.HttpClient.New(HttpClient.java:321)
        at sun.net.www.http.HttpClient.New(HttpClient.java:306)
        at sun.net.www.http.HttpClient.New(HttpClient.java:301)
        at 
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:
469)
        at 
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:460)
        at 
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:887)
        at 
org.apache.jmeter.protocol.http.sampler.HTTPSampler.sample(HTTPSampler.java:415)
        at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:137)
        at java.lang.Thread.run(Thread.java:536)

It does NOT matter whether I "clear all" between runs; same
problem either way.

If I add a "Connection: close" HTTP header, the problem does NOT
occur -- but if that distorts the measurements, it isn't a useful
workaround.


Analysis:

What's happening is that the underlying sockets aren't being
closed, and eventually the JVM bumps into the system's
per-process limit on open file descriptors.

The right solution would be to make the sockets close at the
Right Time (which I guess is when, or shortly after, the server
has closed its end of the connection).  That seems hard with
HttpURLConnection.  It's all very confused:
  - disconnect() just seems to close it immediately -- or not;
    the Javadocs are intentionally vague about what it actually
    does, and especially when it does it.

  - close() might be the right choice.  The Evaluation section of
    Java bug #4147525 says: "... call close() on the input and/or
    output stream. This will correctly result in the underlying
    socket being closed when you aren't doing keepalive
    connections and will correctly cache and reuse keepalive
    connections (and which will timeout and close themselves
    after a short time anyway)."

  - But maybe not.  Bug #4142971 says: "Calling the close()
    methods has no effect one way or the other on whether the
    underlying HTTP connection is persistent."

Failing a clear answer, perhaps the HttpURLConnection objects
could be added to a list, and all disconnected at once at the end
of the test run.  That'd still limit the total size of the run,
but at least the lost descriptors wouldn't accumulate between
runs.

Maybe the real answer is to give up on HttpURLConnection, and
instead use the HTTP Client from Jakarta Commons.  Someone
suggested that in connection with a different problem (bug
#4143518).