[
https://issues.apache.org/jira/browse/BOOKKEEPER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135846#comment-13135846
]
Ivan Kelly commented on BOOKKEEPER-93:
--------------------------------------
My previous comment was incomplete. The changes should be tested also. The
whole reason the bug exists is a lack of testing in the first place. The
easiest thing is to simply extend the BookieReadWriteTest for his case to
ensure that add fails on lhOpen, and that the ledger metadata isn't closed
after lhOpen is called.
Im still confused by the callback issue on readLastConfirmedOp. The only
scenario where the callback can be called twice is where it recieves more
responses than it has requests made. This discussion should continue on
BOOKKEEPER-94.
> bookkeeper doesn't work correctly on OpenLedgerNoRecovery
> ---------------------------------------------------------
>
> Key: BOOKKEEPER-93
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-93
> Project: Bookkeeper
> Issue Type: Bug
> Affects Versions: 3.4.0
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Fix For: 3.4.0
>
> Attachments: bookkeeper-93.patch, bookkeeper-93_v2.patch
>
>
> 1) bookkeeper hang when openLedgerNoRecovery, since LedgerOpenOp didn't
> trigger callback when opening ledger no recovery.
> 2) race condition in ReadLastConfirmOp
> ReadLastConfirmOp callback on readEntryComplete.
> a) first decrement numResponsePending
> b) then increment validResponses
> c) check validResponses to callback with OK
> b) check numResponsePending to callback with LedgerRecoveryException
> support two callbacks returns on readEntryComplete: A, B. (quorum/ensemble
> size : 2)
> a) A first decrement numResponsePending from 2 to 1.
> b) A increment validResponses from 0 to 1.
> c) B then decrement numResponsePending from 1 to 0.
> d) A check numResponsePending before B check validResponse, A found the
> numResponsePending is 0 now. A will callback with exception. But the right
> action is B check validResponse and callback with OK.
> 3) if an LegerHandle is opened by openLedgerNoRecovery, the lastAddConfirmed
> will be set to -1. so all read requests will be failed since readEntry id >
> lastAddConfirmed.
> so I suggested that if an LegerHandle is opened by openLegerNoRecovery, the
> ledgerHandle is under unsafeRead mode. close/write operations will be failed,
> read operations should not check condition entry_id > lastAddConfirmed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
