1

I am trying to analyse one of our applications running in production, and currently the value of javax.net.ssl.sessionCacheSize is set to 10000.

we are using java 17 in production, and by default in Java 17, value of javax.net.ssl.sessionCacheSize is set to 20480.

I wanted to understand what happens when this sessionCacheSize becomes full? Does it trigger a GC event (We use G1GC in Prod)? Or application response times would go high? or application won't accept new connect until the existing connections get dropped and cache has some space to create the session?

Ajay Kumar
  • 586
  • 5
  • 21
  • 1
    @tgdavies For a single SSL connection it has zero effect, because that holds a hard reference to its current session. However, as I understand it, connections can switch sessions, and multiple connections can share a session. If a session is no longer in the cache, it will probably result in some form of renegotiation to establish a new session. – Mark Rotteveel Jul 14 '23 at 11:12

1 Answers1

3

In Adoptium OpenJDK 17.0.7 (and thus also other OpenJDK derivatives), the session cache is implemented in sun.security.util.MemoryCache, which you should be able to inspect in your IDE. This class uses a LinkedHashMap as an LRU (Least Recently Used) style cache, together with expiration and - optionally - reference tracking . When any method is invoked, it will expunge any cache items which are only softly reachable, and for some methods it will expunge expired entries.

If after adding new items in the cache, the size exceeds the configured maximum (even after expunging expired entries), it will remove the least recently used items until the cache size is within bounds.

This by itself does not trigger any GC, but will produce some garbage which will eventually be collected. It will also not prevent new sessions from being created.

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
  • Perfect. This is what I was looking for. – Ajay Kumar Jul 14 '23 at 11:09
  • Also, If I keep the value of this to be 10k, then the only downside I see If I'm creating too many connections frequently and this cache uses LRU, it will evict more items to be able to create new connections which would eventually produce more garbage for GC to pick (in future or right now depends)? Am I correct? – Ajay Kumar Jul 14 '23 at 11:13
  • I think the downside is that sessions evicted from the cache can't be resumed, and have to be renegotiated. How often TLS attempts to resume sessions I'm not sure... – tgdavies Jul 14 '23 at 11:14
  • -Djavax.net.ssl.sessionCacheSize=10000 here 10k; is it in bytes? or in KB? Could you please confirm this as well? – Ajay Kumar Jul 14 '23 at 11:14
  • @AjayKumar Basically yes, however, I wouldn't touch the setting unless you have clearly established that you need to change it. Don't just change it because a previous Java version used a different default. – Mark Rotteveel Jul 14 '23 at 11:14
  • 2
    @AjayKumar No, it is the number of sessions in the cache. – Mark Rotteveel Jul 14 '23 at 11:16
  • 1
    Incase some future soul comes to comment: here is the link to the file: https://github.com/twosigma/OpenJDK/blob/master/src/java.base/share/classes/sun/security/util/Cache.java#L249 – Ajay Kumar Jul 14 '23 at 11:54
  • @Mark This needs to be specified properly for `SSLSessionContext`: not necessarily the LRU part but at least a statement that some session will be evicted and therefore cease to be resumeable, Or whatever the specification is supposed to be. – user207421 Jul 14 '23 at 11:56
  • @user207421 That is covered by the documentation of [`SSLSession`](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/javax/net/ssl/SSLSession.html): _"Sessions may be invalidated due to policies affecting security or resource usage, or by an application explicitly calling invalidate. Session management policies are typically used to tune performance."_ – Mark Rotteveel Jul 14 '23 at 12:15