Github user ifesdjeen commented on a diff in the pull request:
https://github.com/apache/cassandra/pull/278#discussion_r223868092
--- Diff:
src/java/org/apache/cassandra/service/reads/repair/AbstractReadRepair.java ---
@@ -102,12 +104,24 @@ void sendReadCommand(Replica to, ReadCallback
readCallback, boolean speculative)
else type = to.isFull() ? "full" : "transient";
Tracing.trace("Enqueuing {} data read to {}", type, to);
}
- MessageOut<ReadCommand> message = command.createMessage();
- // if enabled, request additional info about repaired data from
any full replicas
- if (command.isTrackingRepairedStatus() && to.isFull())
- message =
message.withParameter(ParameterType.TRACK_REPAIRED_DATA,
MessagingService.ONE_BYTE);
- MessagingService.instance().sendRRWithFailure(message,
to.endpoint(), readCallback);
+ if (to.isSelf())
+ {
+ try (ReadExecutionController executionController =
command.executionController();
--- End diff --
Yes, you're absolutely right: it is wrong to block this thread for I/O. We
in fact have a pattern in order to deal with these things on local execution
path:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/AbstractReadExecutor.java#L157
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/reads/ShortReadPartitionsProtection.java#L186
Thanks for pointing that out!
---
---------------------------------------------------------------------
To unsubscribe, e-mail: pr-unsubscr...@cassandra.apache.org
For additional commands, e-mail: pr-h...@cassandra.apache.org
