You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2022/08/31 17:02:15 UTC

[GitHub] [pulsar] poorbarcode commented on a diff in pull request #17264: [improve][broker]Recover as much cursor data as possible, even if entry is invalid

poorbarcode commented on code in PR #17264:
URL: https://github.com/apache/pulsar/pull/17264#discussion_r959822776


##########
managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java:
##########
@@ -553,6 +505,66 @@ protected void recoverFromLedger(final ManagedCursorInfo info, final VoidCallbac
         }
     }
 
+    private void recoverCursorByLedgerEntry(long entryId, VoidCallback callback, ManagedCursorInfo info,
+                                            LedgerHandle recoveredFromCursorLedger){
+        recoveredFromCursorLedger.asyncReadEntries(entryId, entryId, (rc1, lh1, seq, ctx1) -> {
+            if (log.isDebugEnabled()) {
+                log.debug("[{}} readComplete rc={} entryId={}", ledger.getName(), rc1, lh1.getLastAddConfirmed());
+            }
+            boolean tryPreviousEntry = Code.NoSuchEntryException == rc1 && entryId > 0;
+            if (tryPreviousEntry) {
+                recoverCursorByLedgerEntry(entryId - 1, callback, info, recoveredFromCursorLedger);

Review Comment:
   I've changed the logic to binary search. And I have a question: will there be intermittent entry loss like this: `[x, null, x, null...]`. If this scenario exists, the binary search is not appropriate.



-- 
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: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org