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] [Updated] (CASSANDRA-2034) Make Read Repair unnecessary when Hinted Handoff is enabled
Date Fri, 19 Aug 2011 22:37:27 GMT

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

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

    Attachment: 2034-v18.txt

bq. hintsInProgress.incrementAndGet(); happens outside of the executor and actually before
scheduling it

You're right, I mis-read that.

bq. I process the callback after the message expired. If the CL was achieved (and the requirement
for a hint are gathered) I return true for this target meaning that a hint needs to be written.


Actually I think this does not achieve our goal of making read-repair unnecessary.  For that,
we need to always hint when an attempted write fails.

bq. I think I prefer make the user wait for RPCTimeout 

That's reasonable.

v18 attached (applies on top of 17).  I've added waiting for hints to finish to MS.shutdown,
added a call to MS.shutdown from the shutdown hook, and added a call to stopRPCServer from
the shutdown hook and from drain.  (This is important, because there is nothing else to prevent
new messages from being added to MS's callback map.)


> 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, 2034-v17.txt, 2034-v18.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

        

Mime
View raw message