poorbarcode commented on code in PR #20128:
URL: https://github.com/apache/pulsar/pull/20128#discussion_r1171246436
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/GeoPersistentReplicator.java:
##########
@@ -183,6 +188,7 @@ protected boolean replicateEntries(List<Entry> entries) {
msg.getMessageBuilder().clearTxnidLeastBits();
// Increment pending messages for messages produced locally
PENDING_MESSAGES_UPDATER.incrementAndGet(this);
+ lastSent = entry.getPosition();
Review Comment:
> It looks like the inflight messages will also be treated as lastSent?
Yes, it was done on purpose. Because there has a scenario like this:
- start sending messages `1~3` to the remote cluster, and it is not finished
yet(`lastSent` is 0 now).
- <strong>(Highlight)</strong>receive messages `4~5`. these messages will be
discarded and trigger a rewind. This will reduce the efficiency of task
Replication.
If we update the variable `lastSent` when the sending is started, it will
works like this:
- start sending messages `1~3` to the remote cluster, and it is not finished
yet(`lastSent` is 3 now).
- receive messages `4~5` and send them(`lastSent` is 5 now).
- <strong>(Highlight)</strong>the message `3` failed to send, call
`rewind`(`markDeleted` is 2 now) and set the variable `lastSent` to `earliest`.
- Because the timeout of the producer is `0`, the probability of this
scenario occurring is very, very small.
- receive the message `3` the second time. because `3 > max(2, earliest)`,
the check `hasMessageSkipped` will be pass
--
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]