[jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops

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

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

Jonathan Ellis commented on CASSANDRA-2819:
-------------------------------------------

- read_repair is a write and should use that timeout
- should distinguish b/t multirow (range/index) reads, and single-row lookups
- REQUEST_RESPONSE should drop based on what kind of query the request being responded to was
- ExpiringMap should use expiration of max (read, read multirow, write)
- which means the REQUEST_RESPONSE drop-messages block isn't entirely redundant wrt ExpiringMap, but if it's too difficult to look up what the message type was it's probably not a big deal to ignore
- DD.getRpcTimeout should be removed and replace w/ the appropriate op timeout.  If there are any internal operations that rely on rpctimeout (can't think of any that do) then we may want to add an "internal" timeout as well.  (Or it may be evidence of a bug and we should fix it.)

> Split rpc timeout for read and write ops
> ----------------------------------------
>
>                 Key: CASSANDRA-2819
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2819
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Stu Hood
>            Assignee: Melvin Wang
>             Fix For: 1.0
>
>         Attachments: rpc-rw-timeouts.patch
>
>
> Given the vastly different latency characteristics of reads and writes, it makes sense for them to have independent rpc timeouts internally.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira