Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not-shard-aware port fallback policy should be optional #123

Open
vladzcloudius opened this issue Jun 6, 2023 · 2 comments
Open

Not-shard-aware port fallback policy should be optional #123

vladzcloudius opened this issue Jun 6, 2023 · 2 comments

Comments

@vladzcloudius
Copy link

vladzcloudius commented Jun 6, 2023

What version of Scylla or Cassandra are you using?

2022.2.6

What version of Gocql are you using?

HEAD: e38b2bc

Description
Scylla shard-aware driver has a not very practical fallback connection policy which core is here: https://github.com/scylladb/gocql/blob/master/scylla.go#L407

In gist it is going to fall back to a "storm" connection policy where the driver is going to open and close TCP sockets till all shards are populated if a connection to a shard-aware port (by default 19042) fails for any reason.

But if a connection fails for any reason except for actual misconfiguration this policy is only going to make things worse.
For example, if a connection to 19042 timed out because a corresponding shard is overloaded sending even more sockets in a storm-like manner is only going to add up to the overload.

I suggest to make such a fallback optional (via some configurable) so that people who know how to configure their systems and networking can disable it.

Ref #122

@vladzcloudius
Copy link
Author

vladzcloudius commented Jun 6, 2023

cc @isburmistrov

@dkropachev
Copy link
Collaborator

True, but we need to consider many cases, like tablets, busy shard(connection) handling, lwt handling, other type of partitioners.
Other part of the issue that could be handled at the same place is host policy/prioritization/filtering based on dc/rack.

We might want to come up with something that unifies all the variants/configurations under one umbrella join together HostSelectionPolicy and ConnPicker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants