lhotari opened a new pull request, #25684: URL: https://github.com/apache/pulsar/pull/25684
### Motivation `BrokerService.monitorBacklogQuota` runs every `backlogQuotaCheckIntervalInSeconds` and iterates **every persistent topic on the broker** via `forEachPersistentTopic` ([BrokerService.java:2476](https://github.com/apache/pulsar/blob/master/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BrokerService.java#L2476)). For each topic it calls `BacklogQuotaManager.handleExceededBacklogQuota`, which mutates managed-ledger cursor state via `slowestConsumer.skipEntries` and `markDeletePositionMoveForward` (see [BacklogQuotaManager.java:140-213](https://github.com/apache/pulsar/blob/master/pulsar-broker/src/main/java/org/apache/pulsar/broker/service/BacklogQuotaManager.java#L140-L213)). Today this runs unconditionally — including on topics that have already been **fenced** (e.g. transient ledger-interceptor exception) or are **closing/deleting** (`fenceTopicToCloseOrDelete()` sets `isClosingOrDeleting = true` and `isFenced = true`). When a namespace is being force-deleted under quota pressure, the checker concurrently mutates cursor state on a topic the delete path is trying to tear down. The two compete for the same managed-ledger / cursor, slowing the deletion. This was observed as intermittent `Awaitility.deleteNamespace` timeouts in `BacklogQuotaManagerTest` — see https://github.com/apache/pulsar/actions/runs/25387367872/job/74455105884 (PR #25676 attempt 1). A test-side workaround for the symptom is in #25680; this PR addresses the underlying broker behavior. ### Modifications Early-return at the top of `BacklogQuotaManager.handleExceededBacklogQuota` if the topic reports `isFenced()` or `isClosingOrDeleting()`: ```java if (persistentTopic.isFenced() || persistentTopic.isClosingOrDeleting()) { // entries are about to be discarded — running eviction is wasted work // and contends with the close/delete path return; } ``` Both methods are auto-generated by Lombok `@Getter` on the existing fields (`AbstractTopic.isFenced`, `PersistentTopic.isClosingOrDeleting`). No new accessors needed. ### Verifying this change - [x] Make sure that the change passes the CI checks. This change is already covered by existing tests, such as `BacklogQuotaManagerTest.testConsumerBacklogEvictionSizeQuotaCleansPendingAcks` and `BacklogQuotaManagerTest.testConsumerBacklogEvictionTimeQuotaNotPreciseCleansPendingAcks` (the normal-path eviction is exercised; both pass locally with this change applied). The skipped path (fenced/closing topic) is a correctness no-op: the entries to be evicted are about to be discarded anyway by the close/delete pipeline, so the only observable effect is the absence of redundant cursor mutations during teardown. ### Does this pull request potentially affect one of the following parts: - [ ] Dependencies (add or upgrade a dependency) - [ ] The public API - [ ] The schema - [ ] The default values of configurations - [ ] The threading model - [ ] The binary protocol - [ ] The REST endpoints - [ ] The admin CLI options - [ ] The metrics - [ ] Anything that affects deployment -- 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]
