lhotari commented on PR #25101: URL: https://github.com/apache/pulsar/pull/25101#issuecomment-3686227883
> @lhotari Maybe we should do `asyncMarkDelete` if we reach this condition? Since this is the root casue to inconsistency. > > https://github.com/apache/pulsar/blob/fbab357fdc28992b59512c355ebf06b29eef4f2e/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedLedgerImpl.java#L3010-L3012 @oneby-wang I guess that could make sense, however the problem is that there could be multiple cursors at the slowest position. `ManagedCursorContainerImpl/ManagedCursorContainer` doesn't have a sorted data structure which could be iterated. `ActiveManagedCursorContainer` has the method `getNumberOfCursorsAtSamePositionOrBefore` which solves this detail. It's currently used for `activeCursors` in `ManagedLedgerImpl` when `cacheEvictionByExpectedReadCount` is enabled. It would be possible to use it also for other use cases. The performance of `ActiveManagedCursorContainerImpl` is better than `ManagedCursorImpl` also for the ordinary use cases. There are micro benchmarks in the `microbench` module. However, it might be better to handle it separately. Just wondering if it's already handled by the `advanceCursorsIfNecessary` method: https://github.com/apache/pulsar/blob/fbab357fdc28992b59512c355ebf06b29eef4f2e/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedLedgerImpl.java#L3109-L3116 -- 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]
