JDK-8210985 : Update the default SSL session cache size to 20480
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 8,11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-09-20
  • Updated: 2021-01-18
  • Resolved: 2018-11-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 8 Other
11.0.5Fixed 12 b23Fixed 8u261Fixed openjdk8u222Fixed
Related Reports
CSR :  
JDK-8213577 - Update the default SSL session cache size to 20480
Relates :  
JDK-8253764 - Log a warning once sessionCacheSize reaches to set value
Relates :  
JDK-8211017 - Support TLS 1.3 session resumption without server-side state
Relates :  
JDK-8253116 - Performance regression observed post upgrade to 8u261
Relates :  
JDK-8255603 - Memory/Performance regression after JDK-8210985
Relates :  
JDK-8259886 - Improve SSL session cache performance and scalability
Relates :  
JDK-8213579 - Document the System Property, javax.net.ssl.sessionCacheSize
Sub Tasks
JDK-8240229 :  
Release Note: Default SSL Session Cache Size Updated to 20480 - Resolved
JDK-8240230 :  
Release Note: Default SSL session cache size updated to 20480 - Resolved
Description
The default value for the maximum number of entries in the SSL session cache (which is a SoftReference cache) is infinite, and the entry timeout is 24 hours. With larger heaps, we've run into situations where the cache ends up with several million entries at the 24 hour mark, at which time many of them are invalidated at almost the same time, which can result in multi-minute pauses, which are effectively service failures. We (Amazon) have experimented with using 10k as the default maximum number of entries with good results: i.e., no latency increases due to sessions falling out of the cache.

The session cache size can be set via SSLSessionContext.setSessionCacheSize() or via the javax.net.ssl.sessionCachSize, but not everyone knows about these or uses them, so a change in the default value would be worth investigating.
Comments
Fix Request 8u. I've filed backport and CSR issues, JDK-8224769 and JDK-8224770. Webrev at http://cr.openjdk.java.net/~phh/8210985/webrev.8u.00/.
24-05-2019
Fix Request 11u. I've filed backport and CSR issues, JDK-8224765 and JDK-8224766. Patch applies cleanly.
24-05-2019
It would be good if we could get this backported to OpenJDK 11u and introduce a default upper bound for the number of cache entries.
17-05-2019
Hi Paul, I'm removing the fix request while the review issue is being sorted. Note: this isn't a rejection! Once you've obtained a review for the backport you can add the request keyword again and I'll approve.
13-12-2018
This patch cannot be applied as it alters the SSLSessionContext spec. A separate patch for backporting will need to be submitted / reviewed on the security-dev alias.
07-12-2018
Fix Request This fix solves a continuing problem at Amazon, so we'd like to backport it to jdk11u. It's a minimal low risk change and adds bound checking on the sessionCacheSize property. The patch applies cleanly.
06-12-2018
See also related thread on security-dev: http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018168.html
02-10-2018