[
https://issues.apache.org/jira/browse/BOOKKEEPER-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13873592#comment-13873592
]
Sijie Guo commented on BOOKKEEPER-710:
--------------------------------------
{quote}
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.
{quote}
you could implement this polling mechanism in ledger manager (for metastore
that doesn't support watcher/notification) to satisfy the listener interface in
the patch. that's ok.
but for metastore like zookeeper, they already provide watcher, which we could
leverage to reduce polling traffic to zookeeper. since ensemble change only
happens during bookie node failures, e.g rolling restart, which is a very rare
in most of case. it is not good to introduce too much traffic to zookeeper.
{quote}
Have you stats on how many watches zookeeper can sustain?
{quote}
no. we don't have this number. I assumed that it depends on the memory of
zookeeper. [~fpj] might have idea 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)
