poorbarcode commented on code in PR #4462:
URL: https://github.com/apache/bookkeeper/pull/4462#discussion_r1668946025


##########
bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/HandleFactoryImpl.java:
##########
@@ -64,8 +79,22 @@ public LedgerDescriptor getReadOnlyHandle(final long 
ledgerId) throws IOExceptio
         return handle;
     }
 
+    private void markIfConflictWritingOccurs(long ledgerId) {
+        LedgerDescriptor ledgerDescriptor = ledgers.get(ledgerId);
+        try {
+            if (ledgerDescriptor != null && ledgerDescriptor.isFenced()) {
+                recentlyFencedAndDeletedLedgers.put(ledgerId, true);
+            }
+        } catch (IOException | BookieException ex) {
+            // The ledger is in limbo state.
+            recentlyFencedAndDeletedLedgers.put(ledgerId, true);
+        }
+    }
+
     @Override
     public void ledgerDeleted(long ledgerId) {
+        markIfConflictWritingOccurs(ledgerId);

Review Comment:
   > If the bk client opens the ledger by openLedgerNoRecovery, the service 
won't mark the ledger as a fenced state. The fenced state is caused by bk 
client open the ledger with recover mode. Of cause, this fix can fix the issue 
we encountered in Pulsar.
   
   If the BK client opens the ledger by `openLedgerNoRecovery`, does it mean 
this client will only read data from the ledger and never `close/delete` it?
   
   If yes, only the first writable ledger handler will delete the ledger, so we 
can confirm there is a bug in the client who opens the ledger by 
`openLedgerNoRecovery` if it deleted the ledger. Please correct the behavior if 
my understanding is wrong.



-- 
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]

Reply via email to