[
https://issues.apache.org/jira/browse/CASSANDRA-2819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073795#comment-13073795
]
Melvin Wang commented on CASSANDRA-2819:
----------------------------------------
looks like readcallback, repaircallback, abstractWriteresponseHandler all
assume the timeout value from getRpcTimeout(); however with this patch,
ExpiringMap will timeout different messages with different values, so we may
have situation where expiringMap already expires the message while the get()
still blocks if we have different read_rpc_timeout/write_rpc_timeout with the
'default' rpc timeout. I'm wondering if we could modify the IAsyncCallback so
that we expiringMap expires a message, it will signal the callback and mark it
as a failure, and hence in get() we don't need to have the logic to track the
timeout.
> 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: 2819-v4.txt, rpc-jira.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
