[CASSANDRA-13880] Fix short read protection for tables with no clustering columns

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 3.0.15, 3.11.1
• Component/s: Legacy/Coordination
• Severity: Normal
• Assignee: Aleksey Yeschenko
• Reporter: Aleksey Yeschenko

Authors

Aleksey Yeschenko

Reviewers

Benedict Elliott Smith

• Created: 15/Sep/17 19:18
• Updated: 16/Apr/19 09:29
• Resolved: 19/Sep/17 10:21

Description

CASSANDRA-12872 fixed counting replica rows, so that we do now fetch more than one extra row if necessary.

Fixing the issue caused consistency_test.py:TestConsistency.test_13747 to start failing, by exposing a bug in the way we handle empty clusterings.

When moreContents() asks for another row and lastClustering is EMPTY, the response again (and again) contains the row with EMPTY clustering.

SRP assumes it’s a new row, counts it as one, gets confused and keeps asking for more, in a loop, again and again.

Arguably, a response to a read command with the following non-inclusive ClusteringIndexFilter:

command.clusteringIndexFilter(partitionKey).forPaging(metadata.comparator, Clustering.EMPTY, false);

... should return nothing at all rather than a row with an empty clustering.

Also arguably, SRP should not even attempt to fetch more rows if lastClustering == Clustering.EMPTY. In a partition key only column
we shouldn’t expect any more rows.

This JIRA is to fix the latter issue on SRP side - to modify SRP logic to short-circuit execution if lastClustering was an EMPTY one instead of querying pointlessly for non-existent extra rows.