[CASSANDRA-15442] Read repair implicitly increases read timeout value

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 4.0-alpha3, 4.0
• Component/s: Legacy/Core
• Labels: pull-request-available
• Bug Category: Availability - Response Crash
• Severity: Low
• Complexity: Normal
• Discovered By: Code Inspection
• Platform: All
• Since Version: 4.0-alpha

Source Control Link

https://github.com/apache/cassandra/commit/9abe2127dde7ea317928b37b8b5c662e787b2192

Test and Documentation Plan

circle

• Assignee: Yifan Cai
• Reporter: Yifan Cai

Authors

Yifan Cai

Reviewers

Blake Eggleston, Jordan West

• Created: 03/Dec/19 17:58
• Updated: 21/Dec/20 08:07
• Resolved: 16/Dec/19 23:48

Description

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

1. Regular read, wait for full data/digest read response to complete. reads[*].awaitResponses();
2. Read repair read, wait for full data read response to complete. reads[*].awaitReadRepair();
3. 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.

Issue Links

• relates to: CASSANDRA-2494 Quorum reads are not monotonically consistent
• relates to: CASSANDRA-14635 Support table level configuration of monotonic reads
• links to: GitHub Pull Request #391