Adding sleep to solve racing conditions is a bad practice, and should be
avoided if possible. Instead, use read and write CL that guarantees
strong consistency when it is required/needed.
On 09/08/2022 23:49, Jim Shaw wrote:
Raphael:
Have you found root cause ? If not, here are a few
Raphael:
Have you found root cause ? If not, here are a few tips, based on what
I experienced before, but may not be same as your case, just hope it is
helpful.
1) app side called wrong code module
get the cql from system.prepared_statements
cql statement is helpful to developers to search
You're right too, this option is not new, sorry.
Is this option can be useful ?
Le dim. 7 août 2022, 22:18, Bowen Song via user
a écrit :
> Do you mean "nodetool settraceprobability"? This is not exactly new, I
> remember it was available on Cassandra 2.x.
> On 07/08/2022 20:43, Stéphane
Do you mean "nodetool settraceprobability"? This is not exactly new, I
remember it was available on Cassandra 2.x.
On 07/08/2022 20:43, Stéphane Alleaume wrote:
I think perhaps you already know but i read you can now trace only a %
of all queries, i will look to retrieve the name of this
Thanks a lot Scott, i didn't knew this fact.
Kind regards
Stéphane
Le dim. 7 août 2022, 19:31, C. Scott Andreas a
écrit :
> > but still as I understand the documentation the read repair should not
> be in the blocking path of a query ?
>
> Read repair is in the blocking read path for the
I think perhaps you already know but i read you can now trace only a % of
all queries, i will look to retrieve the name of this fonctionnality (in
new Cassandra release).
Hope it will help
Kind regards
Stéphane
Le dim. 7 août 2022, 20:26, Raphael Mazelier a écrit :
> > "Read repair is in the
> "Read repair is in the blocking read path for the query, yep"
OK interesting. This is not what I understood from the documentation.
And I use localOne level consistency.
I enabled tracing (see in the attachment of my first msg)/ but I didn't
see read repair in the trace (and btw I tried to
> but still as I understand the documentation the read repair should not be in the blocking path of a query ?Read repair is in the blocking read path for the query, yep. At quorum consistency levels, the read repair must complete before returning a result to the client to ensure the data returned
Read repair chance ?
Le dim. 7 août 2022, 19:25, Raphael Mazelier a écrit :
> Nope. And what really puzzle me is in the trace we really show the
> difference between queries. The fast queries only request read from one
> replicas, while slow queries request from multiple replicas (and not only
Nope. And what really puzzle me is in the trace we really show the
difference between queries. The fast queries only request read from one
replicas, while slow queries request from multiple replicas (and not
only local to the dc).
On 07/08/2022 14:02, Stéphane Alleaume wrote:
Hi
Is there
Well answering to myself this is not related to read_repair chance.
Settings them to 0 change also nothing. So the question remains: why
from time to time C* want to make multiple read on a non local dc ?
On 06/08/2022 12:31, Raphael Mazelier wrote:
Well I tried (but already have some
Well I tried (but already have some whiteListFilter) it changed nothing
but it's more convenient that using whiteListFilter (speeding up the
connection time).
So still from time to time (dedanding of the frequency of my requests) I
got slow request when I notice in the trace that c* try to
The DCAwareRoundRobinPolicy/TokenAwareHostPolicy controlls which
Cassandra coordinator node the client sends queries to, not the nodes it
connects to, nor the nodes that performs the actual read.
A client sends a CQL read query to a coordinator node, and the
coordinator node parses the CQL
I remember gocql.DataCentreHostFilter was used. try add it to see whether
will read local DC only in your case ?
Thanks,
James
On Fri, Aug 5, 2022 at 2:40 PM Raphael Mazelier wrote:
> Hi Cassandra Users,
>
> I'm relatively new to Cassandra and first I have to say I'm really
> impressed by
14 matches
Mail list logo
