Ok you're right, I get your point
LIKE '%%esc%' --> startWith('%esc')
LIKE 'escape%%' --> = 'escape%'
What I strongly suspect is that in the source code of SASI, we parse the %
xxx % expression BEFORE applying escape. That will explain the observed
behavior. E.g:
LIKE '%%esc%' parsed as %xxx%
hi all,
we are using quorum consistency, and we *suspect* there may be a race
condition during the write. lets say RF is 3. so write will wait for at
least 2 nodes to ack. suppose there is only 1 node acked(node A). the other
2 nodes(node B, C) are still waiting to update. there come two read requ
Hi,
Sending a message to user-unsubscr...@cassandra.apache.org is the right way
to go if you want to unsubscribe from the "Cassandra User" mailing list,
C*heers,
---
Alain Rodriguez - @arodream - al...@thelastpickle.com
France
The Last Pickle - Apache Cassandra Consulting
htt
Hi,
the analysis is valid, and strong consistency the Cassandra way means that
one client writing at quorum, then reading at quorum will always see his
previous write.
Two different clients have no guarantee to see the same data when using
quorum, as illustrated in your example.
Only options here
Hi,
Sending a message to user-unsubscr...@cassandra.apache.org is the right way
to go if you want to unsubscribe from the "Cassandra User" mailing list,
C*heers,
---
Alain Rodriguez - @arodream - al...@thelastpickle.com
France
2016-09-12 18:02 GMT+02:00 Spencer Brown :
> ub
Hi,
I was curious if anyone had any kind of statistics or ballpark figures on how
long it takes information to propagate through a cluster with Gossip? I'm
particularly interested in how fast information about the liveness of a node
spreads. For example, in an n-node cluster the median amount
Hi Alex:
Hmmm ... Assuming clock skew is eliminated And assuming nodes are up and
available ... And assuming quorum writes and quorum reads and everyone waiting
for success ( which is NOT The OP scenario), Two different clients will be
guaranteed to see all successful writes, or be told tha
My understanding of the described scenario is that the write hasn't
succeeded when reads are fired, as B and C haven't processed the mutation
yet.
There would be 3 clients here and not 2 : C1 writes, C2 and C3 read.
So the race condition could still happen in this particular case.
Le mer. 14 sep
Hi,
In my opinion the guaranty provided by Cassandra is :
if your write request in Quorum *succeed*, then the next (after the
write response) read requests in Quorum (that succeed too) will be
consistent
(actually CL.Write + CL.Read > RF)
Of course while you haven't received a valid r
On Wed, Sep 14, 2016 at 3:49 PM, Nicolas Douillet <
nicolas.douil...@gmail.com> wrote:
> -
> - during read requests, cassandra will ask to one node the data and to
> the others involved in the CL a digest, and if all digests do not match,
> will ask for them the entire data, handle the merge and f
thanks Surabhi; we'll do further tests regarding this. The per node tps are
less, but for the overall cluster the tps are like 90k.
On Tue, Sep 13, 2016 at 3:25 PM, Surbhi Gupta
wrote:
> We have seen a little overhead in latencies while enabling the
> client_encryption.
> Our cluster gets around
Thanks a lot. That was really good info.
On Tue, Sep 13, 2016, 15:41 G P wrote:
> Read this:
>
> http://www.aifb.kit.edu/images/5/58/IC2E2014-Performance_Overhead_TLS.pdf
>
> It can cause bigger variances in latencies, but not much.
> Terça-feira, 13 Setembro 2016, 08:01PM +01:00 de sai krishnam
I haven't been very accurate in my first answer indeed, which was
misleading.
Apache Cassandra guarantees that if all queries are ran at least at quorum,
a client writing successfully (as in the cluster acknowledged the write)
then reading his previous write will see the correct value unless anothe
13 matches
Mail list logo
