cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Melvin Wang (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2819) Split rpc timeout for read and write ops
Date Mon, 01 Aug 2011 21:28:50 GMT


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:
>             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:


View raw message