SSL session cache default maximum number of entries

[Sean Mullan]

On 9/12/18 2:25 PM, Hohensee, Paul wrote:
> Thanks very much for investigating. We're aware that the cache size can be set by the user, but many of our users haven't done so because it hasn't been necessary, and boom.

Would you mind filing a bug and we will look into it?

Thanks,
Sean

> 
> Paul
> 
> On 9/11/18, 12:49 PM, "core-libs-dev on behalf of Sean Mullan" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.mullan at oracle.com> wrote:
> 
>      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
>      >>
>      
>