[
https://issues.apache.org/jira/browse/CASSANDRA-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13553018#comment-13553018
]
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: https://issues.apache.org/jira/browse/CASSANDRA-4858
> 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, 4858-v3-2.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: http://www.atlassian.com/software/jira
