Uh oh!
There was an error while loading. Please reload this page.
Shard aware support - #6
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
vladzcloudius
commented
Mar 12, 2020
Please, don't squash commits - you can always do it later. |
Uh oh!
There was an error while loading. Please reload this page.
ultrabug
commented
Apr 8, 2020
Hi guys, as discussed on Slack I've pushed the changes necessary to a more graceful shard aware connection pooling ;) |
fruch
commented
Apr 13, 2020
@vladzcloudius care to take a look at the test in 5b636fc. I guess you have some more ideas, on how/what should be test in that regards |
vladzcloudius
commented
Apr 14, 2020
@fruch I'd like to see how driver behaves when you tear connections down: send RST from the remote side. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
* unit test for parsing and shard_id calculation * integration test using trace to verify requests going to the correct shard
since the async callback, to be on the safe side, adding a lock to the `set.remove()` call
refactor the logic of re-opening connection to all shards into it's own function so we can reuse it in `_replace()`
base on @ultrabug comment, changing the debug print to be more clear and informative
based on @ultrabug comments, this should be named better
base on @ultrabug comments, this would be faster.
Better explian why do we loop at max twice over the shards in this function.
Protocol does not (yet?) allow clients to specify which shard they want to connect to and thus depend on a round-robin allocation of the shard_id made by the host node (see system.clients table). This means that on a live cluster where client connections come and go, we cannot guarantee that we will get a connection to every shard... even by retrying twice (which slows down the connection startup also) This commit switches to use an optimistic approach where we try to connect as many times as there are shards on the remote cluster at first. Then when routing_key is used and shard aware connection picking can take place, we will try to open missing connections as we detect them. This is more graceful and allows us to not fail if we miss shard connections as well as reduce the connection startup time! A long running client will hopefully get a connection to all shards after a while! That's the best we can do for now until the protocol evolves.
Initial connection tentatives to shards are now scheduled instead of being blocking on startup. This allows the shard aware driver to connect to a Scylla cluster as fast as Cassandra one!
* add test for multiple client at the same time * add test for closing connections * add test for blocking(timing out) connections
On busy systems we could overwhelm the threadpool executor queue with repeated submissions of speculative shard connections to the same shard which results in having an unbound number of connection openings to scylla nodes This could be seen as a "connection leak" and was also not respecting the signal of cluster connections shutting down
fruch
commented
Jun 2, 2020
@ultrabug FYI, I've rebase and force pushed this branch (not very social of me.. but I want travis to start working ontop of this PR too) |
No description provided.