[
https://issues.apache.org/jira/browse/CASSANDRA-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13462510#comment-13462510
]
Lior Golan commented on CASSANDRA-4705:
---------------------------------------
How about just letting the user configure a threshold, above which a backup
request will be sent?
This can be an easy way to start with this feature (saving the need to estimate
the p99 point).
It will allow what Peter is suggesting above (just set the threshold to 0), and
will allow the user to tune the tradeoff between latency and throughput.
It would be cool to be able to set this threshold on a per request basis,
similar to how CL is specified.
But thinking about this a bit more - isn't such a feature better implemented at
the client library level? Implementing this at the client library level will
also allow handling cases where the StorageProxy is down (i.e. GC at the
coordinator), and would make it easier to specify at the per request level (no
need to pollute the protocol with this setting)
> Speculative execution for CL_ONE
> --------------------------------
>
> Key: CASSANDRA-4705
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4705
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: 1.2.0
> Reporter: Vijay
> Assignee: Vijay
> Priority: Minor
>
> When read_repair is not 1.0, we send the request to one node for some of the
> requests. When a node goes down or when a node is too busy the client has to
> wait for the timeout before it can retry.
> It would be nice to watch for latency and execute an additional request to a
> different node, if the response is not received within average/99% of the
> response times recorded in the past.
> CASSANDRA-2540 might be able to solve the variance when read_repair is set to
> 1.0
> 1) May be we need to use metrics-core to record various Percentiles
> 2) Modify ReadCallback.get to execute additional request speculatively.
--
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
