[
https://issues.apache.org/jira/browse/CASSANDRA-15442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Eggleston updated CASSANDRA-15442:
----------------------------------------
Status: Changes Suggested (was: Review In Progress)
Thanks Yifan, feedback below:
* The configured write timeout no longer factors in to the timeout
calculation. I'd expect repair writes to timeout on the write timeout, or
whatever is remaining on the read timeout. Whichever is less. WDYT?
* {{awaitRepairsUntil doesn't follow the }}convention of taking a {{TimeUnit}}
argument
* DistributedReadWritePathTest
** {{Assert.fail("Read timeout expected but it did not occur”);}} can go right
after the statement you're expecting to throw ({{cluster.coordinator(1).ex...),
instead of setting and checking a boolean.}}
** You could get a further confirmation things are working are expected by
setting the write timeout to a value 2-3x above the read timeout.
** Since you're only blocking the write responses. you could confirm the
timeout came from the write by checking the mutations repaired the recipients.
> 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 share the same timeout, and wait 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 ~7 s,
> if each individual step does not exceed the timeout value.
> From the client perspective, it may not expect a request taken 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
