On Fri, 21 Jun 2024 15:35:46 GMT, Anthony Scarpino <ascarp...@openjdk.org> wrote:
> Let me start from the beginning and hopefully it will clear things up. > > Today, each Finished connection gets one resumption ticket. That session's > SSLContext contains the cache. When someone wants to resume, they use the > same SSLContext to make a new session. That new session will look into the > cache, find the resumption ticket, and take it out to use. Tickets are > one-time use. On completion of the resumed session, a new ticket is placed > into cache under the same entry as the previous one. > > Clients that want to open parallel sessions are unable to use resumption > effectively. The current client cache can only hold one ticket, throwing away > any other tickets the server may have sent it. Additionally, the time between > taking the resumption ticket and receiving a new ticket is too slow for > parallel connecting clients. The first resumption session takes that ticket, > while the second resumption session sees no ticket and has to do a full > handshake. This change allows multiple tickets to be stored on the client > cache, solving the parallel clients problem, without the application having > to change. > > If the application uses new SSLContext instances for each connection, it does > not have access to the same cache. This change does not modify that. Thanks for this clarification. I was not clear how can multiple connections apply all the cached tickets in parallel. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19465#issuecomment-2183575943
