Details
-
Bug
-
Resolution: Not an Issue
-
P4
-
None
-
14
Description
ADDITIONAL SYSTEM INFORMATION :
Our applications are a little constrained on memory and therefore runs the SerialGC by default. This particular issue has been seen on a debian openjdk docker image (openjdk:14.0.1-slim-buster), but probably goes for all openjdk 14.0.1-implementations.
A DESCRIPTION OF THE PROBLEM :
When upgrading to Java 14, we noted a significant increase in memory usage. After debugging, we noticed having jdk.tls.client.enableSessionTicketExtension=true (as is the default in 14.0.1), causes all the handshake-sessions to be cached in the clientCache in SSLContextImpl.java, preventing or at least significantly delaying garbage collection. The problem seems to arise in ServerHello.java around line 1125, where the handshake session gets an id and therefore ends up in the cache in Finished.java (lines 553-556). This may be by design but it seems that those entries keyed on the sessionId are never read afterwards.
In our case we have a PostgreSQL database pool (Hikari), that creates SSL connections with half-an-hour lifetime and then throws them away (connection.close()). However, this problem manifests itself in the clientCache (and heap usage) growing significantly over time, making almost the entire heap filled with SSLSocketImpl and friends. For someone (like myself) not particularly into the details of SSL it is certainly surprising to see the heap usage grow by several 100 percent after upgrading to Java 14.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create an application with a HikariCP database connection pool using an SSL-enabled PostgreSQL database, using default options. Run with the SerialGC(?). Limit the available memory to easier spot the problem.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The heap should be reasonably filled.
ACTUAL -
The heap grows significantly each time Hikari creates new connections and throws away the old ones.
Our applications are a little constrained on memory and therefore runs the SerialGC by default. This particular issue has been seen on a debian openjdk docker image (openjdk:14.0.1-slim-buster), but probably goes for all openjdk 14.0.1-implementations.
A DESCRIPTION OF THE PROBLEM :
When upgrading to Java 14, we noted a significant increase in memory usage. After debugging, we noticed having jdk.tls.client.enableSessionTicketExtension=true (as is the default in 14.0.1), causes all the handshake-sessions to be cached in the clientCache in SSLContextImpl.java, preventing or at least significantly delaying garbage collection. The problem seems to arise in ServerHello.java around line 1125, where the handshake session gets an id and therefore ends up in the cache in Finished.java (lines 553-556). This may be by design but it seems that those entries keyed on the sessionId are never read afterwards.
In our case we have a PostgreSQL database pool (Hikari), that creates SSL connections with half-an-hour lifetime and then throws them away (connection.close()). However, this problem manifests itself in the clientCache (and heap usage) growing significantly over time, making almost the entire heap filled with SSLSocketImpl and friends. For someone (like myself) not particularly into the details of SSL it is certainly surprising to see the heap usage grow by several 100 percent after upgrading to Java 14.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create an application with a HikariCP database connection pool using an SSL-enabled PostgreSQL database, using default options. Run with the SerialGC(?). Limit the available memory to easier spot the problem.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The heap should be reasonably filled.
ACTUAL -
The heap grows significantly each time Hikari creates new connections and throws away the old ones.