cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tata (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-497) Include bootstrap targets in consistencylevel computations
Date Tue, 20 Oct 2009 22:35:59 GMT


Sandeep Tata commented on CASSANDRA-497:

> Yes it does, because reads just use getReadStorageEndPoints, which correctly ignores

Which is exactly why it might violate consistency guarantees. Here's an example:

Key k lives on A, B, C. Node  N is being bootstrapped for this range.

write(k, ConsistencyLevel.ONE) : blocks for 1 response, say this was from Node N.

read(k, ConsistencyLevel.ONE) --> gets data from one replica, say A. Node A might not yet
have gotten the previous write (only N did): this violates the consistency semantics.

> Include bootstrap targets in consistencylevel computations
> ----------------------------------------------------------
>                 Key: CASSANDRA-497
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Jonathan Ellis
>            Assignee: Jonathan Ellis
>            Priority: Minor
>             Fix For: 0.5
>         Attachments: 0001-CASSANDRA-497-rename-nodePicker-replicationStrategy.txt, 0002-make-write-targets-computable-independent-of-replicati.txt,
0003-Make-EndPoint-objects-immmutable-so-hashcode-can-t-ch.txt, imports.patch
> We want to preserve ConsistencyLevel semantics during bootstrap, and if a CL.quorum/all
write is sent to a bootstrap target, it would have to wait for the forwarded write to complete
to report in turn that the write is good.
> Leaving write propagation to be done by the write originator means we don't have this
extra layer of latency.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message