Issue
We are using openJDK11.0.6 java.net.http HTTP (HTTP1.1) client to fetch content from websites. After a long execution time, we noticed a performance decrease. CPU is 100% used even when the app does nothing. We were able to determine that it comes from a lot of app leaked socket (CLOSE-WAIT state).
There is already some question about it here (like this one), but all submitted bugs are supposed to be fixed and backported to java 11.0.6.
I've been able to reproduce the bug into a minalist project on github. It seems it happens only when the client receives a 204 NO-CONTENT from the server.
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpClient.Version;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;
public class BasicFetcherApp {
public static void main(String[] args) throws Exception {
System.out.println("App is running... pid: " + ProcessHandle.current().pid());
HttpClient client = HttpClient.newBuilder().version(Version.HTTP_1_1).build();
for (int i = 0; i < 10; ++i) {
HttpRequest request =
HttpRequest.newBuilder(URI.create("http://localhost:4001/nocontent")).build();
HttpResponse<String> response = client.send(request, BodyHandlers.ofString());
System.out.println(String.format("Response HTTP status: %s", response.statusCode()));
}
System.out.println("Finish");
System.in.read();
}
}
If we run it :
App is running... pid: 23306
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Response HTTP status: 204
Finish
ss -np | grep 23306
u_str ESTAB 0 0 * 4121660 * 0 users:(("java",pid=23306,fd=13))
u_str ESTAB 0 0 * 4121047 * 0 users:(("java",pid=23306,fd=6))
tcp ESTAB 0 0 [::ffff:127.0.0.1]:56666 [::ffff:127.0.0.1]:40177 users:(("java",pid=23306,fd=7))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58592 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=24))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58570 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=18))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58572 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=19))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58564 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=15))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58560 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=14))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58574 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=20))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58582 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=21))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58590 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=23))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58594 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=25))
tcp CLOSE-WAIT 1 0 [::ffff:127.0.0.1]:58584 [::ffff:127.0.0.1]:4001 users:(("java",pid=23306,fd=22))
OpenJDK bug (fixed):
Solution
This might be https://bugs.openjdk.java.net/browse/JDK-8216974 which has been fixed in JDK 13
Answered By - daniel
Answer Checked By - David Marino (JavaFixing Volunteer)
