cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-497) Include bootstrap targets in consistencylevel computations
Date Tue, 20 Oct 2009 22:07:59 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12767971#action_12767971
] 

Jonathan Ellis edited comment on CASSANDRA-497 at 10/20/09 10:06 PM:
---------------------------------------------------------------------

Thanks for taking a look!

> 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.

      was (Author: jbellis):
    > 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.


Mime
View raw message