New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SocketException: Too many open files #929
Comments
Mike Stover (migrated from Bugzilla): I'd also like to know what happens if you run with keep-alive on, run till you The Jakarta HTTPClient has some problems in terms of use with JMeter. The |
Mike Stover (migrated from Bugzilla): |
Mike Stover (migrated from Bugzilla): Let me know how it works out. |
Jordi Salvat i Alabart (migrated from Bugzilla): |
Jordi Salvat i Alabart (migrated from Bugzilla): |
Eric Siegerman (Bug 12007):
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:
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).
Severity: major
OS: Linux
The text was updated successfully, but these errors were encountered: