[
https://issues.apache.org/jira/browse/CASSANDRA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767971#action_12767971
]
Jonathan Ellis commented on CASSANDRA-497:
------------------------------------------
> Reads are never directed to bootstrapping nodes, so the app should be
> insulated from having to reason about bootstrap for its consistency
> guarantees. The current logic doesn't guarantee that
Yes it does, because reads just use getReadStorageEndPoints, which correctly
ignores bootstrap-in-progress.
determineBlockFor just says "given a set of nodes we're writing [or reading,
but actually read just hardcodes N / 2 + 1 right now] to, how many do we need
to form a quorum." So you'd control it by giving it the right set of nodes to
reason about.
> Had to add Set and HashSet to imports to get it to build .. probably because
> patch missed a hunk?
Sorry about that -- trunk has moved a bunch since that was generated.
> 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.
