[
https://issues.apache.org/jira/browse/CASSANDRA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767989#action_12767989
]
Sandeep Tata commented on CASSANDRA-497:
----------------------------------------
> Yes it does, because reads just use getReadStorageEndPoints, which correctly
> ignores bootstrap-in-progress.
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: https://issues.apache.org/jira/browse/CASSANDRA-497
> 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.
