Motivation

About cursor deleting, there are two cases

• scenario-A: Acked nothing, because all positions have been acknowledged before.
• scenario-B: Acked some position, then it will try to mark-deleted.
  • scenario-B1: Acked some positions, but individualDeletedMessages became empty after combining ranges in the method setAcknowledgedPosition,
  • scenario-B2: Acked some positions, and individualDeletedMessages was still not empty.

Triggering callbacks

• Regarding the scenario-A, Cursor will skip calling mark-deleted, because it is meaningless.
• Regarding the scenario-B, Cursor will call mark-deleted, which will trigger a callback.

Issue
Regarding the scenario-B1, the Cursor triggers twice the callbacks.

• The first time: calls the callback if individualDeletedMessages is empty. https://github.com/apache/pulsar/blob/master/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java#L2479

boolean empty = individualDeletedMessages.isEmpty();
if (empty) {
    callback.deleteComplete(ctx);
}

• The first time: calls the callback after calling mark-deleted. https://github.com/apache/pulsar/blob/master/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java#L2499

internalAsyncMarkDelete(newMarkDeletePosition, properties, new MarkDeleteCallback() {
        @Override
        public void markDeleteComplete(Object ctx) {
            callback.deleteComplete(ctx);
        }
}

Modifications

To confirm the scenario matches scenario-A, rather than confirming individualDeletedMessages.isEmpty, use a specific variable to record it.

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: x