[jira] [Commented] (CASSANDRA-4705) Speculative execution for CL_ONE

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-4705:
-------------------------------------------

avro is just used for upgrading from 1.0 schemas, so shouldn't need to touch that anymore.

Would it make more sense to have getReadLatencyRate and UpdateSampleLatencies into SR?  that way we could replace case statements with polymorphism.

Can you split the AbstractReadExecutor refactor out from the speculative execution code?  That would make it easier to isolate the changes in review.

Why does preprocess return a boolean now?

How does/should SR interact with RR?  Using ALL + RRR means we're probably going to do a lot of unnecessary "repair" writes in a high-update environment (i.e., it would be normal for one replica to be slightly behind others on a read), which is probably not what we want.  Also unclear to me what happens when we use RDR and do a SR when we've also requested extra digests for RR, and we get a data read and a digest from the same replica.
                
> 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
>         Attachments: 0001-CASSANDRA-4705.patch, 0001-CASSANDRA-4705-v2.patch
>
>
> 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