[
https://issues.apache.org/jira/browse/BOOKKEEPER-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873575#comment-13873575
]
Ivan Kelly commented on BOOKKEEPER-710:
---------------------------------------
I've been thinking about this very scenario lately, and really, I think
readLastAddConfirmed is just a broken api. The correct thing to do here would
be to do an openNoRecovery() in the loop. This will only involve metadata reads
from ZK/metastore, and these should be very fast, given they're going to
memory. Have you stats on how many watches zookeeper can sustain?
> OpenLedgerNoRecovery should watch ensemble change.
> --------------------------------------------------
>
> Key: BOOKKEEPER-710
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-710
> Project: Bookkeeper
> Issue Type: Bug
> Components: bookkeeper-client
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Priority: Blocker
> Fix For: 4.3.0, 4.2.3
>
> Attachments: BOOKKEEPER-710.diff
>
>
> LedgerHandle opened by openLedgerNoRecovery should watch ensemble change.
> otherwise, readLastConfirmed & readEntries will stuck if there are ensemble
> changes in the ledger.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
