Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <851903325.9581270559493463.JavaMail.jira@brutus.apache.org>
Date: Tue, 6 Apr 2010 13:11:33 +0000 (UTC)
From: "Hudson (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Commented: (CASSANDRA-930) make RR chance configurable
In-Reply-To: <1593525328.569891269917007916.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Hudson commented on CASSANDRA-930:
----------------------------------

Integrated in Cassandra #399 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/399/])
    

> make RR chance configurable
> ---------------------------
>
>                 Key: CASSANDRA-930
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-930
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Matthew F. Dennis
>            Priority: Minor
>             Fix For: 0.7
>
>         Attachments: CASSANDRA-930.patch
>
>
> Read load increases linearly with replication factor.  While this can be mitigated by simply adding machines, it would also be nice to be able to configure on a per-CF basis the chance of performing a read repair, so that particularly heavily read CFs could have a chance of (say) 10% and seldom-used ones could continue to repair every time, i.e., chance of 100%.  Thus, the "hot keys get repaired before waiting for anti-entropy to kick in" property gets preserved, but you might see a few more reads serving old values than before.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.