cassandra-commits mailing list archives

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

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

Sandeep Tata commented on CASSANDRA-497:
----------------------------------------

1. Making getReadStorageEndPoints the only method a replicationstrategy needs to implement
is a nice move. Looks good.

2. I see the value in including bootstrapping nodes in the blockFor calculations. 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:
determineBlockFor will need to be fixed.

You need to block for (#bootstrapping nodes + #determined as if there were no bootstrapping
nodes).

For instance, if there's one node that's being bootstrapped in the range of interest, ConsistencyLevel.ONE
should block for *2* not *1* so that a read is guaranteed to hit at least one copy.

ALL will work correctly. QUORUM will work correctly for cases where only 1 node is being bootstrapped
for this range, 



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