maedhroz commented on a change in pull request #1180:
URL: https://github.com/apache/cassandra/pull/1180#discussion_r702060997
##########
File path: src/java/org/apache/cassandra/db/ReadCommand.java
##########
@@ -632,6 +654,84 @@ private void maybeDelayForTesting()
}
}
+ private UnfilteredPartitionIterator
withQuerySizeTracking(UnfilteredPartitionIterator iterator)
+ {
+ if (!trackWarnings ||
SchemaConstants.isSystemKeyspace(metadata().keyspace)) // exclude internal
keyspaces
Review comment:
Say we have RF=3, and we're always issuing a speculative read during a
QUORUM query. If the local node is providing a digest response, it is possible
for there to be a mismatch when the other two replicas respond, and then for
the local node to, on a separate thread, execute a read-repair-driven data
read. In that case, are we guaranteed that `trackWarnings` will be properly
visible to that other thread (a `ReadStage` thread)?
Generally, I want to make sure we have our heads wrapped around the paths in
the code (read-repair, short read protection, replica filtering protection)
that hit `Stage.READ.maybeExecuteImmediately()` and can transfer execution to
`ReadStage` threads while mutable state is perhaps being relied on in
`ReadCommand`. For instance, the approach CASSANDRA-16721 took around this was
moving as much as possible relating to a local read through the local read
runnable itself, which, once it starts executing, isn't going to randomly
switch threads.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
