-
Notifications
You must be signed in to change notification settings - Fork 138
Description
As mentioned by @wprzytula in #1029 driver tries to open control connection sequentially to the contact points - meaning that it moves to next contact point only after opening the connection to the previous one failed.
This may not always be the desired behavior.
The other possible improvements are:
- Try opening connections to multiple contact points at the same time, as described in Try opening initial control connection to all known contact points simultaneously #1111
- Prefer local DC for control connection Prefer the local DC for control connections #559
If we implement DC awareness, we should first implement #1440 so that setting local DC needs to only be done in one place.
I think that instead of adding such options directly on SessionConfig, we could do it differently, more in line with how similar stuff is implemented in other parts of the driver:
- Introduce ControlConnectionPolicy trait. It would get info about contact points (and other peers after metadata is known), and decide to which of them we should try opening the connection.
- Similarly to LoadBalancingPolicy, we would implement a single default control connection policy. The builder of this policy would expose options described above - randomization and concurrency control.
Is there any reason to not do it this way? I don't think so, so I'll close the other 2 issues in favor of this one. If it turns out this approach is not the right one we can reopen them.