artemlivshits commented on code in PR #14629:
URL: https://github.com/apache/kafka/pull/14629#discussion_r1372270435
##########
core/src/main/scala/kafka/server/ReplicaManager.scala:
##########
@@ -846,7 +759,8 @@ class ReplicaManager(val config: KafkaConfig,
producerId = batchInfo.producerId,
producerEpoch = batchInfo.producerEpoch,
topicPartitions = notYetVerifiedEntriesPerPartition.keySet.toSeq,
- callback =
KafkaRequestHandler.wrap(appendEntries(entriesPerPartition)(_))
+ callback =
KafkaRequestHandler.wrap(appendEntries(entriesPerPartition,
internalTopicsAllowed, origin, requiredAcks, verificationGuards.toMap,
Review Comment:
I think the way it's implemented right know is that we're just continuing
processing from the current point after the network operation has completed, so
as far as the "application" logic is concerned, the machinery to resume the
execution on the request pool is hidden from the "application" logic. This
allows to do an arbitrary number of non-blocking waits with minimal disruption
of the application logic flow (the change is localized in the point of
non-blocking wait).
In this case we could inject a new produce request (if I understand your
question correctly) with some context saying that it's "verified", but I think
it'd be more intrusive as we'd need to implement some produce-specific
"verified" context (that would have to include verification guard and whatnot)
and pass it down through all functions. We'd also need to consider the offset
commit path, which is a separate path that eventually comes to this function.
Also, if we consider a more general functionality (we don't have any, but
hopefully, if we make Kafka more async there will be more cases), generally
we'd want to preserve the progress that has been made until the network call,
so if a request would need to work work XYZ and we have non-blocking network
calls between stages, it would be good that the overall work would be X [RPC] Y
[RPC] Z, rather than X [RPC] XY [RPC] XYZ.
--
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]
