Hi Paul,
Thank you for bringing this issue to our attention. While we agree that
this does indeed seem like an issue that should be addressed, it is
quite late in the JDK 11 schedule, and it does not appear to be a new
issue introduced in JDK 11. We will be investigating this offline and
will get back to you as soon as we can with more details. Offhand, I
think that we would be able to change the default in an update release.
Also, you are probably already be aware of this, but you can use the
SSLSessionContext.setSessionCacheSize() API as well as the
"javax.net.ssl.sessionCacheSize" system property to customize the cache
size.
--Sean
On 9/11/18 12:02 PM, Sean Mullan wrote:
cross-posting to security-dev since this is related to SSL/TLS.
On 9/11/18 11:41 AM, Hohensee, Paul wrote:
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’re running into situations
where the cache ends up with several million entries when the 24 hours
are up. They’re then all invalidated at the same time, resulting in
multi-minute pauses (effectively service failures). We’ve 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). It’s late and a long shot for JDK11: we’d love to see it
changed there because 11 is an LTS release and this is, at least
nominally, a behavior change which might not be acceptable in 11u.
What do people think?
Thanks,
Paul
