cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2494) Quorum reads are not monotonically consistent
Date Thu, 11 Aug 2011 15:35:27 GMT


Sylvain Lebresne commented on CASSANDRA-2494:

bq. Well, sort of – rpctimeout is working exactly as intended, i.e., to prevent waiting
indefinitely for a node that died after we sent it a request. Treating it as "max time to
respond to client" has never really been correct. (E.g., in the CL > ONE case we can already
wait up to rpctimeout twice, one for the original digest read set, and again for the data
read after mismatch.) So I don't think we should try to be clever with that here.

Fair enough. It would probably be useful to make rpctimeout meaning closer to "max time to
respond to client". Created CASSANDRA-3018 for that though.

+1 on v2.

> Quorum reads are not monotonically consistent
> ---------------------------------------------
>                 Key: CASSANDRA-2494
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Sean Bridges
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 1.0
>         Attachments: 2494-v2.txt, 2494.txt
> As discussed in this thread,
> Quorum reads should be consistent.  Assume we have a cluster of 3 nodes (X,Y,Z) and a
replication factor of 3. If a write of N is committed to X, but not Y and Z, then a read from
X should not return N unless the read is committed to at  least two nodes.  To ensure this,
a read from X should wait for an ack of the read repair write from either Y or Z before returning.
> Are there system tests for cassandra?  If so, there should be a test similar to the original
post in the email thread.  One thread should write 1,2,3... at consistency level ONE.  Another
thread should read at consistency level QUORUM from a random host, and verify that each read
is >= the last read.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message