You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Blake Eggleston (Jira)" <ji...@apache.org> on 2019/12/03 18:41:00 UTC

[jira] [Updated] (CASSANDRA-15442) Read repair implicitly increases read timeout value

     [ https://issues.apache.org/jira/browse/CASSANDRA-15442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Blake Eggleston updated CASSANDRA-15442:
----------------------------------------
    Reviewers: Blake Eggleston

> Read repair implicitly increases read timeout value
> ---------------------------------------------------
>
>                 Key: CASSANDRA-15442
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15442
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/Core
>            Reporter: Yifan Cai
>            Assignee: Yifan Cai
>            Priority: Normal
>
> When read repair occurs during a read, internally, it starts several _blocking_ operations in sequence. See {{org.apache.cassandra.service.StorageProxy#fetchRows}}. 
>  The timeline of the blocking operations
>  # Regular read, wait for full data/digest read response to complete. {{reads[*].awaitResponses();}}
>  # Read repair read, wait for full data read response to complete. {{reads[*].awaitReadRepair();}}
>  # Read repair write, wait for write response to complete. {{concatAndBlockOnRepair(results, repairs);}}
> Step 1 and 2 each waits for the duration of read timeout, say 5 s.
>  Step 3 waits for the duration of write timeout, say 2 s.
>  In the worse case, the actual time taken for a read could accumulate to ~12 s, if each individual step does not exceed the timeout value.
>  From the client perspective, it does not expect a request taken way higher than the database configured timeout value. 
>  Such scenario is especially bad for the clients that have set up client-side timeout monitoring close to the configured one. The clients think the operations timed out and abort, but they are in fact still running on server.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org