-
Bug
-
Resolution: Incomplete
-
P4
-
8, 11, 12
-
x86_64
-
linux
ADDITIONAL SYSTEM INFORMATION :
Current Debian Strech x64
A DESCRIPTION OF THE PROBLEM :
When we load-tested JDK 11.0.2 and Jetty for 90 seconds, we noted that the machines that were overloaded kept busy for a long time (around 90s) after the load test was finished (e.g. all clients killed).
This happens because the JDKs SSL implementation is doing those expensive RSA operations even for closed sockets. We verified this by sampling the JVM after the test was finished: Nearly two thirds of the CPU time were spent in `java.math.BigInteger.oddModPow ()`.
This behavior makes no sense at all and could be very harmful. In real life, sockets could get closed due to browser timeouts, users that leave the overloaded website or even on purpose by attackers.
We tried this with JDK 11, JDK 12 and JDK 1.8. The problem was reproducible on all of those JVMs.
See https://github.com/eclipse/jetty.project/issues/3367 for more details regarding the test setup.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Overload the system by doing the double of the SSL handshakes that the SUT is capable of for 90s
2. Stop the load test
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The CPU load on the SUT should drop a few seconds after the load test was finished.
ACTUAL -
The SUT stays busy for around 90s.
FREQUENCY : always
Current Debian Strech x64
A DESCRIPTION OF THE PROBLEM :
When we load-tested JDK 11.0.2 and Jetty for 90 seconds, we noted that the machines that were overloaded kept busy for a long time (around 90s) after the load test was finished (e.g. all clients killed).
This happens because the JDKs SSL implementation is doing those expensive RSA operations even for closed sockets. We verified this by sampling the JVM after the test was finished: Nearly two thirds of the CPU time were spent in `java.math.BigInteger.oddModPow ()`.
This behavior makes no sense at all and could be very harmful. In real life, sockets could get closed due to browser timeouts, users that leave the overloaded website or even on purpose by attackers.
We tried this with JDK 11, JDK 12 and JDK 1.8. The problem was reproducible on all of those JVMs.
See https://github.com/eclipse/jetty.project/issues/3367 for more details regarding the test setup.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Overload the system by doing the double of the SSL handshakes that the SUT is capable of for 90s
2. Stop the load test
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The CPU load on the SUT should drop a few seconds after the load test was finished.
ACTUAL -
The SUT stays busy for around 90s.
FREQUENCY : always