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]

Reply via email to