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]