cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4858) Coverage analysis for low-CL queries
Date Mon, 14 Jan 2013 19:26:12 GMT


Sylvain Lebresne commented on CASSANDRA-4858:

bq. Can we use dynamic_snitch_badness_threshold or add something similar instead?

I'm not sure reusing the dynamic_snitch_badness_threshold is appropriate here. Typically,
the default dynamic_snitch_badness_threshold of 0.1 feels like a fairly bad value for the
concern here. And besides, dynamic_snitch_badness_threshold has it's own use that is separate.
We can of course add a new setting here, though 1) it's somewhat pushing the burden to the
user and 2) if we create a setting, it should be a setting that make sense and I'm not sure
exactly what that would be (in particular, I'm far from claiming the heuristic of my second
patch is perfect (it is possible it is "good enough" however)). 
> Coverage analysis for low-CL queries
> ------------------------------------
>                 Key: CASSANDRA-4858
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Vijay
>             Fix For: 1.2.1
>         Attachments: 0001-CASSANDRA-4858.patch, 0001-CASSANDRA-4858-v2.patch, 4858-v3-1.txt,
> There are many cases where getRangeSlice creates more
> RangeSliceCommand than it should, because it always creates one for each range
> returned by getRestrictedRange.  Especially for CL.ONE this does not take
> the replication factor into account and is potentially pretty wasteful.
> A range slice at CL.ONE on a 3 node cluster with RF=3 should only
> ever create one RangeSliceCommand.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message