codelipenghui commented on code in PR #20951:
URL: https://github.com/apache/pulsar/pull/20951#discussion_r1287929641
##########
pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BacklogQuotaManager.java:
##########
@@ -268,4 +271,29 @@ private void disconnectProducers(PersistentTopic
persistentTopic) {
});
}
+
+ private void advanceSlowestMessageDeduplicationCursor(PersistentTopic
persistentTopic,
+ BacklogQuotaType
backlogQuotaType) {
+
+ if (backlogQuotaType != destination_storage) {
+ return;
+ }
+
+ MessageDeduplication dedup = persistentTopic.getMessageDeduplication();
+ if (dedup == null) {
+ return;
+ }
+
+ ManagedLedgerImpl mLedger = (ManagedLedgerImpl)
persistentTopic.getManagedLedger();
+ ManagedCursor slowestConsumer = mLedger.getSlowestConsumer();
+ if (slowestConsumer == null) {
+ return;
+ }
+
+ if (!PersistentTopic.isDedupCursorName(slowestConsumer.getName())) {
+ return;
+ }
+
+ dedup.takeSnapshot();
Review Comment:
The system cursor should never cause the producer disconnection because the
backlog quota is a user-facing policy. Users should not care about the system
cursors when configuring the backlog quota policy. So even if users had
provided a meaningless time-based snapshot duplication policy. The producer
shouldn't be blocked.
Of course, honoring the interval check and the latest changes looks good to
me. Instead of taking snapshots too frequently, we let the backlogs run over
the quota. It makes more sense because we should choose the policy with minimum
impact on the production environment.
--
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]
