You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although it's an old issue, I'm familiar with the implementation of the shard aware port support and I can answer what is going on here.
This is intended behavior. gocql maintains separate connection pools for each node. A pool first tries to establish a single connection to the non-shard-aware port. During handshake, the pool learns about the shard-aware port, and from now on directs new connections to the shard-aware port. The pool doesn't attempt to close the first connection and re-open it to the shard-aware port as it isn't really necessary. Until the first connection will be reopened due to other reasons, it will stay connected to non-shard-aware port.
In addition to this, the driver maintains a single control connection which isn't a part of any pool. I don't think the driver bothers to use the shard-aware port for it at all.
Assuming N nodes and S shards, you should have N + 1 non-shard-aware connections and (S - 1) * N shard-aware connections. I suppose here N = 1 and S = 14, so there should be 2 non-shard-aware connections and 13 shard-aware ones.
Please answer these questions before submitting your issue. Thanks!
What version of Scylla or Cassandra are you using?
What version of Gocql are you using?
1.5.0
What version of Go are you using?
1.16.9
What did you do?
update scylla-bench to use gocql 1.5.0
connected with scylla-bench to a cluster
accessed one of the servers
as can be seen there are:
I expected the control connection to be on 9042 and all the rest of the connections (actually sending traffic) to be on 19042
Maybe the first connection is not the control connection ?
I guess there is an explanation for this - yet am not sure what it is.
The text was updated successfully, but these errors were encountered: