lhotari commented on PR #15067: URL: https://github.com/apache/pulsar/pull/15067#issuecomment-1106430732
> > This patch fixes this problem #15151 > > Could you explain why this patch has fixed this issue ? This line was missing: https://github.com/apache/pulsar/blob/8c534dbcb8daab8a249501604a9312ff4b5a1166/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java#L1616 Since #15031 added a solution to prevent race conditions in updating the `lastMarkDeleteEntry` field, the solution prevented the value to move backwards. The `lastMarkDeleteEntry` field should be resetted in the `initializeCursorPosition` method for this logic to work correctly when using earliest initialposition: https://github.com/apache/pulsar/blob/b083e9a72227a3360d1ec33b5f239d82f0804e65/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedLedgerImpl.java#L935-L942 What ended up happening that #15031 prevented updating the `lastMarkDeleteEntry` field and when the scheduled flush call happened, that updated the markDelete position to the latest position. https://github.com/apache/pulsar/blob/8c534dbcb8daab8a249501604a9312ff4b5a1166/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java#L3123-L3129 That caused the behavior that the cursor would move the readPosition to the last entry when the flush call happened and the resulted in the entries (messages) to be skipped. I'm planning to add a test case to reproduce this and I'll use it also for refactoring the solution to fix the remaining ordering issue / race condition that remains. -- 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]
