[WIP]KAFKA-9893: Configurable TCP connection timeout and improve the initial metadata fetch #8544
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.
*More detailed description of your change,
Selector
The Selector class will now take the new config CONNECTIONS_TIMEOUT_MS_CONFIG in its constructions.
idleExpiryManager
Currently, we have an idleExpiryManager that uses the LRU algorithm evicting the oldest idle connected socket channels. Similarly, we can instantiate a new LinkedHashMap to keep those socket channels initiating the connection and evict the timeout channels.
Currently, all the channels will be kept on the same LRU map. We will split the connected socket channels and connecting socket channels into different LRU map (we will call them "lruConnectingConnections" and "lruConnectedConnections" later).
Here's the state transition:
When the socket channel is initiating the connection, we will put the socket channel to the lruConnectingConnections.
When the connection is successfully built, we will move the channel from lruConnectingConnections into lruConnectedConnections.
In each selector poll, we will remove the oldest timeout socket channel in both lruConnectingConnections and lruConnectedConnections, if possible.
LeastLoadedNodeProvider
Currently, when no nodes provided in --boostrap-server option is connected, the LeastLoadedNodeProvider will provide an unconnected node for the client. The Cluster class shuffled the nodes to balance the initial pressure and the LeastLoadedNodeProvider will always provide the same node, which is the last node after shuffling. Consequently, though we may provide several bootstrap servers, the client not be able to connect to the cluster if any of the servers in the --bootstrap-server list is offline.
I'm changing the provider to interact with the ClusterConnectionStates to determine which node to provide when no connection exists.
ClusterConnectionStates
ClusterConnectionStates will keep the index of the most recently provided node. Meanwhile, a public API looks like below will be added to simulate the round-robin node picking.
public synchronized int nextNodeIdx(int nodeSize) {
return (this.nextNodeIdx++) % nodeSize;
}
The LeastLoadedNodeProvider will provide the nodeSize to prevent the out of bound excpetion.
When the LeastLoadedNodeProvider iterates the node list, it can consult the ClusterConnectionStates for the index of the node it should provide.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)