4.x: Throttle adding channels to ChannelPool #600
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
8d468f2 to
4680d2d
Compare
Adds a new option that allows for throttling `addMissingChannels()` in `ChannelPool.java`. Instead of creating all missing channels at once for particular channel pool the driver will create batches of limited size and handle them sequentially. Setting size 0 means allowing unlimited batches and it will result in the usual behavior of creating channels all at once. The default value is 0. Setting any other size `N`, will result in driver limiting the batches to either `N`, or `ceil(target_total_number_of_pool_connections / 2)`, whichever is smaller. The main motivation for this change is to allow for leveraging TLSv1.3 stateless session resumption using session tickets. Most of the time driver ends up without usable tickets for connecting, mainly due to the way the management of those tickets is done by Java itself. By running connection in batches it allows the driver to obtain some tickets for the next batches, allowing at least some of the connections to avoid negotiation. This feature can also be used outside of this situation. Just throttling should also bring some relief in case of mass reconnections.
Modifies current implementation of `addMissingChannels` in `ChannelPool` to make use of the newly added option. Default behavior remains unchanged.
Adds a method to get contact points with default shard aware port from `ccmBridge`.
Adds `all_reconnections_but_one_should_use_tickets_when_throttled_TLSv13` to `SessionTicketsIT`. This test checks whether throttling reconnections to a batch size of 1 helps with the session resumptions. Since the Java 11 cache can only store information for 1 session resumption this in theory should allow for resumptions to happen if the connections are established sequentially. The test relies on server to send NewSessionTicket messages in a timely manner.
4680d2d to
d0c61a0
Compare
dkropachev
approved these changes
Sep 9, 2025
dkropachev
left a comment
There was a problem hiding this comment.
Looks good, can you please add Fixes: to the PR description and add some information into the issue on why did we solve this issue in such a weird way.
Author
|
Added "Fixes". |
dkropachev
approved these changes
Sep 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds a new option that allows for throttling
addMissingChannels()in
ChannelPool.java. Instead of creating all missing channels at oncefor particular channel pool the driver will create batches of limited size
and handle them sequentially.
Setting size 0 means allowing unlimited batches and it will result in the
usual behavior of creating channels all at once.
The default value is 0.
Setting any other size
N, will result in driver limiting the batches toeither
N, orceil(target_total_number_of_pool_connections / 2),whichever is smaller.
The main motivation for this change is to allow for leveraging TLSv1.3
stateless session resumption using session tickets.
Most of the time driver ends up without usable tickets for connecting, mainly
due to the way the management of those tickets is done by
Java itself (see the linked issue for the details).
By running connection in batches it allows the driver to obtain some tickets
for the next batches, thus allowing at least some of the connections to avoid
negotiation.
Note that it works the best only with OpenJDK version 24 and above, since previous versions
do not cache multiple sessions per host to allow for simultaneous resumption.
Oracle OpenJDK 24 stores at most 10 sessions per host.
I did not check other Java vendors.
This feature can also be used outside of NST session resumption situation. Throttling
by itself should also bring some relief in case of mass reconnections.
Fixes #444.