Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 16 Aug 2011 20:48:27 +0000 (UTC)
From: "Patricio Echague (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: 
 <1367235232.42538.1313527707711.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <9449195.122371295676823976.JavaMail.jira@thor>
Subject: [jira] [Commented] (CASSANDRA-2034) Make Read Repair unnecessary
 when Hinted Handoff is enabled
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Patricio Echague commented on CASSANDRA-2034:
---------------------------------------------

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

Interesting. I must have forgotten it after one of the patches. I remember fixing it before.

{quote}
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.
{quote}

I think I prefer make the user wait for RPCTimeout since it is not that much and perhaps puts a bit more clarity than just saving the hints just in case.

> 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