[
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
