[ 
https://issues.apache.org/jira/browse/CASSANDRA-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jonathan Ellis updated CASSANDRA-2034:
--------------------------------------

    Attachment: 2034-v16.txt

bq. I process the callback after the message expired

That makes sense.

bq. I think the Callback.shoudHint needs an enhancement for when we are during 
shut down in MessagingService

Yes.  We should probably either wait for the messages to time out (which is 
mildly annoying to the user) or just write hints for everything (which may be 
confusing: "why are there hints being sent after I restart, when no node was 
ever down?)  I don't see a perfect solution.

Also, still need to address this:

bq. currentHintsQueueSize [now totalHints] increment needs to be done OUTSIDE 
the runnable or it will never get above the number of task executors

v16 attached: rebased to current head, fixed import ordering, and added some 
comments.

> Make Read Repair unnecessary when Hinted Handoff is enabled
> -----------------------------------------------------------
>
>                 Key: CASSANDRA-2034
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2034
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Patricio Echague
>             Fix For: 1.0
>
>         Attachments: 2034-formatting.txt, 2034-v16.txt, 
> CASSANDRA-2034-trunk-v10.patch, CASSANDRA-2034-trunk-v11.patch, 
> CASSANDRA-2034-trunk-v11.patch, CASSANDRA-2034-trunk-v12.patch, 
> CASSANDRA-2034-trunk-v13.patch, CASSANDRA-2034-trunk-v14.patch, 
> CASSANDRA-2034-trunk-v15.patch, CASSANDRA-2034-trunk-v2.patch, 
> CASSANDRA-2034-trunk-v3.patch, CASSANDRA-2034-trunk-v4.patch, 
> CASSANDRA-2034-trunk-v5.patch, CASSANDRA-2034-trunk-v6.patch, 
> CASSANDRA-2034-trunk-v7.patch, CASSANDRA-2034-trunk-v8.patch, 
> CASSANDRA-2034-trunk-v9.patch, CASSANDRA-2034-trunk.patch
>
>   Original Estimate: 8h
>  Remaining Estimate: 8h
>
> Currently, HH is purely an optimization -- if a machine goes down, enabling 
> HH means RR/AES will have less work to do, but you can't disable RR entirely 
> in most situations since HH doesn't kick in until the FailureDetector does.
> Let's add a scheduled task to the mutate path, such that we return to the 
> client normally after ConsistencyLevel is achieved, but after RpcTimeout we 
> check the responseHandler write acks and write local hints for any missing 
> targets.
> This would making disabling RR when HH is enabled a much more reasonable 
> option, which has a huge impact on read throughput.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to