lhotari commented on code in PR #25571:
URL: https://github.com/apache/pulsar/pull/25571#discussion_r3129254752
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentDispatcherMultipleConsumers.java:
##########
@@ -339,6 +339,24 @@ public void readMoreEntriesAsync() {
}
}
+ @Override
+ public void markDeletePositionMoveForward() {
+ // When the mark-delete position advances (due to ack or TTL expiry),
remove stale entries that are
+ // now below the new mark-delete position from the redelivery tracker
and each consumer's pending acks.
+ synchronized (PersistentDispatcherMultipleConsumers.this) {
+ Position mdp = cursor.getMarkDeletedPosition();
+ if (mdp != null) {
+ redeliveryMessages.removeAllUpTo(mdp.getLedgerId(),
mdp.getEntryId());
+ for (Consumer consumer : consumerList) {
+ PendingAcksMap pendingAcks = consumer.getPendingAcks();
+ if (pendingAcks != null) {
+ pendingAcks.removeAllUpTo(mdp.getLedgerId(),
mdp.getEntryId());
+ }
+ }
Review Comment:
Is there a significant different in the frequency that this gets called?
When this logic was previously in `readMoreEntries`, it would only get called
there if the mark delete position moved since the last call to
`readMoreEntries`, which is not as frequent as the mark delete position might
move forward. This has been intentional behavior in the past and I have a
concern that this change would cause a performance regression.
--
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]
