Skip to content

Implement ControlConnectionPolicy #1279

@Lorak-mmk

Description

@Lorak-mmk

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:

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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions