Created #593 which checks if the feature is supported, however it has to be noted that it's not working as great as it was hoped to work.
In short the main issues are the following:

Older java versions (OpenJDK <24) do not support simultaneous resumption by multiple threads
Even with JDK 24 the behavior is that there are at most 10 sessions cached per host
If driver attempts session resumption while the host is still down, that ticket is effectively wasted. This usually leads to lack of usable tickets when the host is finally up.

Note: some JDK 11 examples below link to OpenJDK code on github. The version I was running was actually

openjdk version "11.0.23" 2024-04-16
OpenJDK Runtime Environment (Red_Hat-11.0.23.0.9-1) (build 11.0.23+9)
OpenJDK 64-Bit Server VM (Red_Hat-11.0.23.0.9-1) (build 11.0.23+9, mixed mode, sharing)

I've left the OpenJDK examples where I think they are equivalent and used decompiled snippets from my IDE where they are not.
For version 24 I've used Oracle OpenJDK 24.0.2.

Cache in Java 11 vs 24

First problem is the sessionHostPortCache in SSLSessionContextImpl class. It is capable of storing
only 1 session per host. In case of Java 11 when this structure is used later on it can be observed that during node restart
all connections will attempt to resume the same session at once and at no point in time does it hold more than 1 entry.
JDK 24 is the first version that seems to have this fixed: https://bugs.openjdk.org/browse/JDK-8328608

JDK 11 Cache and MemoryCache implementation: https://github.com/openjdk/jdk/blob/jdk-11-ga/src/java.base/share/classes/sun/security/util/Cache.java
JDK 11 SSLSessionContextImpl: https://github.com/openjdk/jdk/blob/jdk-11-ga/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java#L40

In JDK 24 the same structure gets a new variation on put, which allows for queueing several elements under the same key:
https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/sun/security/util/Cache.java#L97-L104
https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/sun/security/util/Cache.java#L430-L452

One downside seems to be that the max size of such queue is 10 and it is not configurable.
https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java#L64
https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java#L89-L100

The put and remove methods within SSLSessionContextImpl were also adjusted:
JDK 24: https://github.com/openjdk/jdk/blob/jdk-24-ga/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java#L273-L317
JDK 11: https://github.com/openjdk/jdk/blob/jdk-11-ga/src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java#L166-L194

Behavior on reconnection (JDK 11)

github_java_11_test_logs.txt

Here are some cherry-picked logs from simple reconnection test. There is 1 node with 4 shards and driver is configured to have 1 connection to each shard.
At some point after initial connection the node is stopped and started again.

javax.net.ssl|DEBUG|25|s0-io-0|2025-09-08 20:22:50.877 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|26|s0-io-1|2025-09-08 20:22:51.090 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|28|s0-io-3|2025-09-08 20:22:51.139 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|27|s0-io-2|2025-09-08 20:22:51.142 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|29|s0-io-4|2025-09-08 20:22:51.145 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|2E|s0-io-5|2025-09-08 20:23:03.664 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|2F|s0-io-6|2025-09-08 20:23:03.665 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|30|s0-io-7|2025-09-08 20:23:03.666 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|31|s0-io-8|2025-09-08 20:23:03.668 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|32|s0-io-9|2025-09-08 20:23:05.891 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|33|s0-io-10|2025-09-08 20:23:05.894 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|34|s0-io-11|2025-09-08 20:23:05.894 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|35|s0-io-12|2025-09-08 20:23:05.896 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|39|s0-io-13|2025-09-08 20:23:09.922 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|3A|s0-io-14|2025-09-08 20:23:09.922 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|3B|s0-io-15|2025-09-08 20:23:09.924 CEST|ClientHello.java:642|Produced ClientHello handshake message (
javax.net.ssl|DEBUG|3C|s0-io-16|2025-09-08 20:23:09.929 CEST|ClientHello.java:642|Produced ClientHello handshake message (

Driver clearly attempts to reconnect more than once.

javax.net.ssl|DEBUG|25|s0-io-0|2025-09-08 20:22:50.952 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|25|s0-io-0|2025-09-08 20:22:50.953 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|26|s0-io-1|2025-09-08 20:22:51.109 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|26|s0-io-1|2025-09-08 20:22:51.110 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|28|s0-io-3|2025-09-08 20:22:51.158 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|28|s0-io-3|2025-09-08 20:22:51.160 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|29|s0-io-4|2025-09-08 20:22:51.186 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|27|s0-io-2|2025-09-08 20:22:51.186 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|29|s0-io-4|2025-09-08 20:22:51.186 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|27|s0-io-2|2025-09-08 20:22:51.187 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|3A|s0-io-14|2025-09-08 20:23:09.937 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|39|s0-io-13|2025-09-08 20:23:09.937 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|3A|s0-io-14|2025-09-08 20:23:09.938 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|39|s0-io-13|2025-09-08 20:23:09.938 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|3B|s0-io-15|2025-09-08 20:23:09.944 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|3B|s0-io-15|2025-09-08 20:23:09.945 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|3C|s0-io-16|2025-09-08 20:23:09.946 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (
javax.net.ssl|DEBUG|3C|s0-io-16|2025-09-08 20:23:09.947 CEST|NewSessionTicket.java:328|Consuming NewSessionTicket message (

The tickets are being received and the server sends two tickets for each connection.

javax.net.ssl|DEBUG|26|s0-io-1|2025-09-08 20:22:51.083 CEST|PreSharedKeyExtension.java:679|Found resumable session. Preparing PSK message.
javax.net.ssl|DEBUG|28|s0-io-3|2025-09-08 20:22:51.136 CEST|PreSharedKeyExtension.java:679|Found resumable session. Preparing PSK message.
javax.net.ssl|DEBUG|2F|s0-io-6|2025-09-08 20:23:03.661 CEST|PreSharedKeyExtension.java:679|Found resumable session. Preparing PSK message.

However the driver attempts the resumption only 3 times.
The first connection is the control connection (s0-io-0). After it succeeds it receives 2 tickets. Caches are updated and there is enough time before singular initial connection
from ChannelPool initialization (s0-io-1). This connection also receives two tickets. After that the remaining connections are initialized at the same time (s0-io-2, s0-io-3, s0-io-4).
ClientHello timestamps clealry indicate that s0-io-3 was the first thread to grab the session information from the cache. That's why it's the only thread to use resumption here.
Other logs indicate that io-2 which is the closest to io-3 likely tried to resume the same session:

javax.net.ssl|DEBUG|27|s0-io-2|2025-09-08 20:22:51.139 CEST|PreSharedKeyExtension.java:667|PSK has no identity, or identity was already used

And io-4 already did not find session to resume, since the cache could only store 1 entry and it was removed after being grabbed by io-3.

javax.net.ssl|DEBUG|29|s0-io-4|2025-09-08 20:22:51.143 CEST|PreSharedKeyExtension.java:633|No session to resume.

These logs do not show what is the resumingSession within handshakeContext but another few runs with debugger attached confirmed that this is the scenario that plays out.
To sum up again: when several connections are attempted at the same time, only the first one will manage to grab session information for resumption. Runner ups may also grab
the same PreSharedKey, but synchronization ensures that only one will get to "consume" the PSK identity. The threads that were a little to late will log "PSK has no identity, or identity was already used" and the threads
that were too late to check the cache before the session was removed by the thread that won will log "No session to resume".

There is one more resumption attempted by s0-io-6. This happens right after node stops. This attempt does not succeed, because the node is down. What is of significance here is that there is no resumption attempts afterwards.
The tickets used for failed attempts do not get recycled.

How is ClientHello produced (JDK 11)

ClientHelloKickstartProducer#produce is where it starts:

private static final class ClientHelloKickstartProducer implements SSLProducer {
    public byte[] produce(ConnectionContext context) throws IOException {
      ClientHandshakeContext chc = (ClientHandshakeContext)context;
      chc.handshakeProducers.remove(SSLHandshake.CLIENT_HELLO.id);
      SessionId sessionId = new SessionId(new byte[0]);
      List<CipherSuite> cipherSuites = chc.activeCipherSuites;
      SSLSessionContextImpl ssci = (SSLSessionContextImpl)chc.sslContext.engineGetClientSessionContext();
      SSLSessionImpl session = ssci.get(chc.conContext.transport.getPeerHost(), chc.conContext.transport.getPeerPort());
[...]

session is pulled from sessionHostPortCache through ssci.get(...
Later on (still within produce) if the session is not null this attempt is marked as resumption by setting

chc.isResumption = true;
chc.resumingSession = session;

and finally it goes through the available extensions

SSLExtension[] extTypes = chc.sslConfig.getEnabledExtensions(SSLHandshake.CLIENT_HELLO, chc.activeProtocols);
          chm.extensions.produce(chc, extTypes);

One of these extensions is pre_shared_key and this is the extension that is used for resumption using tickets in TLS 1.3
The important parts to note here are the relevant log messages you may recognize from the previous section and a few extra lines.

private static final class CHPreSharedKeyProducer implements HandshakeProducer {
    public byte[] produce(ConnectionContext context, SSLHandshake.HandshakeMessage message) throws IOException {
      ClientHandshakeContext chc = (ClientHandshakeContext)context;
      if (chc.isResumption && chc.resumingSession != null) {
        Collection<SignatureScheme> sessionSigAlgs = chc.resumingSession.getLocalSupportedSignatureSchemes();
        if (!chc.localSupportedSignAlgs.containsAll(sessionSigAlgs)) {
          if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
            SSLLogger.fine("Existing session uses different signature algorithms", new Object[0]);
          }

          return null;
        } else {
          SecretKey psk = chc.resumingSession.getPreSharedKey();
          if (psk == null) {
            if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
              SSLLogger.fine("Existing session has no PSK.", new Object[0]);
            }

            return null;
          } else {
            if (chc.pskIdentity == null) {
              chc.pskIdentity = chc.resumingSession.consumePskIdentity();
            }

            if (chc.pskIdentity == null) {
              if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
                SSLLogger.fine("PSK has no identity, or identity was already used", new Object[0]);
              }

              return null;
            } else {
              SSLSessionContextImpl sessionCache = (SSLSessionContextImpl)chc.sslContext.engineGetClientSessionContext();
              sessionCache.remove(chc.resumingSession.getSessionId());
              if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
                SSLLogger.fine("Found resumable session. Preparing PSK message.", new Object[0]);
              }

              List<PskIdentity> identities = new ArrayList();
              int ageMillis = (int)(System.currentTimeMillis() - chc.resumingSession.getTicketCreationTime());
              int obfuscatedAge = ageMillis + chc.resumingSession.getTicketAgeAdd();
              identities.add(new PskIdentity(chc.pskIdentity, obfuscatedAge));
              SecretKey binderKey = PreSharedKeyExtension.deriveBinderKey(chc, psk, chc.resumingSession);
              ClientHello.ClientHelloMessage clientHello = (ClientHello.ClientHelloMessage)message;
              CHPreSharedKeySpec pskPrototype = this.createPskPrototype(chc.resumingSession.getSuite().hashAlg.hashLength, identities);
              HandshakeHash pskBinderHash = chc.handshakeHash.copy();
              byte[] binder = PreSharedKeyExtension.computeBinder(chc, binderKey, pskBinderHash, chc.resumingSession, chc, clientHello, pskPrototype);
              List<byte[]> binders = new ArrayList();
              binders.add(binder);
              CHPreSharedKeySpec pskMessage = new CHPreSharedKeySpec(identities, binders);
              chc.handshakeExtensions.put(SSLExtension.CH_PRE_SHARED_KEY, pskMessage);
              return pskMessage.getEncoded();
            }
          }
        }
      } else {
        if (SSLLogger.isOn && SSLLogger.isOn("ssl,handshake")) {
          SSLLogger.fine("No session to resume.", new Object[0]);
        }

        return null;
      }
    }

If we're dealing with resumption and resumingSession has psk available this section will try to call chc.resumingSession.consumePskIdentity();
which will erase this identity from resumingSession.
From SSLSessionImpl:

synchronized byte[] consumePskIdentity() {
    byte[] var1;
    try {
      var1 = this.pskIdentity;
    } finally {
      this.pskIdentity = null;
    }

    return var1;
  }

This means that only the first caller will obtain the pskIdentity.
Additionally if the consuming is successful this part from before will explicitly remove the session from the cache:

SSLSessionContextImpl sessionCache = (SSLSessionContextImpl)chc.sslContext.engineGetClientSessionContext();
sessionCache.remove(chc.resumingSession.getSessionId());

The consuming of psk identity goes a bit different in Oracle OpenJDK 11, but similarly it is not meant to be reused and throughout the code comments about that can be found.
I think these snippets explain the scenario presented in previous section.

Behavior on reconnection (JDK 24)

For the sake of brevity I'll skip adding the logs here.
The situation when using JDK 24 is marginally better.
During initial connection we get a few more resumptions because control connection starts separately and obtains 2 tickets before the initial connection of the ChannelPool which also receives 2 tickets.
If there are 4 shards total the driver will be able to use stored tickets. Only control connection will perform a full handshake. But that is only on initialization.
On reconnection there are several problems:
Reconnection attempts start all at once and if the node is down, the session tickets will be used up during those attemps. Once the node is back up there will likely be no tickets to use.
As mentioned before, the queue is limited to 10 items, so at most 10 tickets per host can be stored.

Other tried avenues

I've briefly tried plugging in Netty's SslContext and using netty-tcnative-boringssl-static or netty-tcnative (for fedora) artifacts.
None brought results where reconnections would fully use resumptions. The reconnections were still almost wholly not resumptions.

Possible workarounds

Come up with our own implementations of ssl classes (a lot of code to recreate and maintain)
Slow down the connections. 4.x: Throttle adding channels to ChannelPool #600 is a possible workaround where connections are established in batches. NewSessionTickets received by previous batches allow next batch to use session resumption.

4.x: Support TLS tickets for quick TLS renegotiation #444

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions