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

Agile Board

Attach files

Attach Screenshot

Bulk Copy Attachments

Bulk Move Attachments

Voters

Watch issue

Watchers

Create sub-task

Convert to sub-task

Move

Link

Clone

Labels

Update Comment Author

Replace String in Comment

Update Comment Visibility

Delete Comments

XML

Word

Printable

JSON

Details

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

None
Since Version:

4.0-alpha
Source Control Link:

https://github.com/apache/cassandra/commit/9abe2127dde7ea317928b37b8b5c662e787b2192
Test and Documentation Plan:

Hide

circle

Show
circle

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

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.