Attaching the runner log snippet, where we can see that "Rebuilding token
map" took most of the time.
getAllroles is using quorum, don't if it is used during login
I suspect some of the intermediate queries (determining role, etc) happen at
quorum in 2.2+, but I don’t have time to go read the code and prove it.
In any case, RF > 10 per DC is probably excessive
Also want to crank up the validity times so it uses cached info longer
--
Jeff Jirsa
> On
no its not a cassandra user and as i understood all other users login
local_one.
On Fri, 23 Nov 2018, 19:30 Jonathan Haddad Any chance you’re logging in with the Cassandra user? It uses quorum
> reads.
>
>
> On Fri, Nov 23, 2018 at 11:38 AM Vitali Dyachuk
> wrote:
>
>> Hi,
>> We have recently
Any chance you’re logging in with the Cassandra user? It uses quorum reads.
On Fri, Nov 23, 2018 at 11:38 AM Vitali Dyachuk wrote:
> Hi,
> We have recently met a problem when we added 60 nodes in 1 region to the
> cluster
> and set an RF=60 for the system_auth ks, following this documentation
Hi,
We have recently met a problem when we added 60 nodes in 1 region to the
cluster
and set an RF=60 for the system_auth ks, following this documentation
https://docs.datastax.com/en/cql/3.3/cql/cql_using/useUpdateKeyspaceRF.html
However we've started to see increased login latencies in the
Hi Alexander,
thanks a lot for the pointers, I checked the mentioned issue.
While the reported issue seems to match our problem it only occurs reads
and not for writes (according to the Datastax Jira). But we experience
downtimes for writes and reads.
Which version of the Datastax Driver
