FULL PRODUCT VERSION :
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux 3.13.0-117-generic #164-Ubuntu SMP Fri Apr 7 11:05:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
When opening many HttpURLConnection to the same host, Java doesn't pool the connections and doesn't re-use SSL sockets.
I dug into the code, and it seems that the ONLY conditions in which connection are pooled, is either when the request method is HEAD, when the content length is 0, or when the response status is 304/204.
Please refer to the code of HttpURLConnection.getInputStream0().
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Connections should be pooled, so not every connection performs an SSL Handshake
ACTUAL -
Connections are not pooled. Every HttpURLConnection performs an SSL Handshake, causing major performance degradation
REPRODUCIBILITY :
This bug can be reproduced always.
java version "1.8.0_102"
Java(TM) SE Runtime Environment (build 1.8.0_102-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Linux 3.13.0-117-generic #164-Ubuntu SMP Fri Apr 7 11:05:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
A DESCRIPTION OF THE PROBLEM :
When opening many HttpURLConnection to the same host, Java doesn't pool the connections and doesn't re-use SSL sockets.
I dug into the code, and it seems that the ONLY conditions in which connection are pooled, is either when the request method is HEAD, when the content length is 0, or when the response status is 304/204.
Please refer to the code of HttpURLConnection.getInputStream0().
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Connections should be pooled, so not every connection performs an SSL Handshake
ACTUAL -
Connections are not pooled. Every HttpURLConnection performs an SSL Handshake, causing major performance degradation
REPRODUCIBILITY :
This bug can be reproduced always.