JDK-8241810 : Connections leaking with state CLOSE_WAIT with java.net.HttpClient
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 11
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux_ubuntu
  • CPU: x86_64
  • Submitted: 2020-03-25
  • Updated: 2020-04-06
  • Resolved: 2020-04-06
Related Reports
Duplicate :  
Description
ADDITIONAL SYSTEM INFORMATION :
I tried with both Oracle Java 11 and OpenJdk 11, I make my tests on my laptop machine which runs Ubuntu  18.04.4 LTS.

A DESCRIPTION OF THE PROBLEM :
I made a little app that's designed to fetch a single page  using java 11 synchronous httpclient. I noticed that, when it receive a 204 no content, the jvm leak a socket with a CLOSE-WAIT status, and disappears only when I close the app. Also, when the app had a lot of CLOSE-WAIT sockets, it CPU consumption increases quite significantly, to the point of slowing down the app.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
I make a small project here to reproduce the bug : https://github.com/navispeed/java11-closewait-socket
Please install mockoon (or a basic http server with a 204 NO CONTENT route) and start it using mockoon.json file. 
Then, start a new java project and make an http client so the app can fetch 10 times the 204 NO CONTENT route, and make the app sleep or waiting for System.in(), so the app will not finish.

Finally, run ss -np | grep <APP pid>

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I'm suppose to see no running socket/local socket used by JMX or something else, and 0 CLOSE-WAIT socket. In case of high number of fetch, at the end, my app should not consume all my CPU if it does nothing.
ACTUAL -
I've got as many CLOSE-WAIT socket as I made fetch.

---------- BEGIN SOURCE ----------
https://github.com/navispeed/java11-closewait-socket
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
If we use 1 http client per fetch per different hostname (and so, GC will destroy it after each fetch), it seems it reduces the CLOSE-WAIT socket count at the end of the test.


Comments
The submitter reported: The issue is well solved in JDK-15. The submitter also asked about the plan of backporting the fix to JDK 11.
02-04-2020

Had submitter to test with http://jdk.java.net/15/ to confirm it is no longer an issue with JDK 15.
02-04-2020

This should have been fixed by JDK-8216974 which was integrated in JDK 13.
31-03-2020

Move to JDK for further evaluation.
30-03-2020