> In NonRecoveryMode, read the entries starting from lastAddConfirmed+1 till
NoSuchEntry comes from all bookies. If all bookies throws NoSuchEntry, then
it is sure that that entry is not written and previous will be the last
available entry.

I don't think it is a good idea to do that. The contract of BookKeeper is
broken. Let me describe a case for you:

1) Client 1 open a ledger to write entries. K is lastAddConfirmed. it is
writing K+1 entry. (BK1, BK2 are expected to write). K+1 has been written
to BK1. But BK2 is not yet.
2) Client 2 openNoRecovery a ledger to read entries. It reads K+1 from BK1
and return.
3) Client 1 failed to add entry to BK2. And if there is no other bookies
alive. the ledger would be closed and client 1 received failed response. so
K+1 is no added actually for the ledger.
4) then what client 2 read doesn't belong to that ledger.

The inconsistency would be introduced if adding the api you suggested.

-Sijie

On Mon, Sep 10, 2012 at 4:54 PM, Vinayakumar B <[email protected]>wrote:

> Hi all,
>
>
>
> While using BookKeeper in BookKeeperJournalManager with HDFS, we faced one
> problem. It cannot read the last entry of the open ledger from different
> BookKeeper client.
>
>
>
> This is due to behavior of bookkeeper to read  upto lastAddConfirmed. For
> the OpenLedger this will be always one less than actual number of entries.
>
>
>
> Problem is ,
>
>
>
>    If the ledger contains one entry, then based on the lastAddConfirmed, we
> cannot decide whether the ledger is actually empty or contains one entry.
>
>
>
>    BKJM needs to read the open ledger without fencing it in case of
> https://issues.apache.org/jira/browse/HDFS-3752.
>
>
>
> So we resolved this internally as below,
>
>  In NonRecoveryMode, read the entries starting from lastAddConfirmed+1 till
> NoSuchEntry comes from all bookies. If all bookies throws NoSuchEntry, then
> it is sure that that entry is not written and previous will be the last
> available entry.
>
> How about adding this addition api to BookKeeper client to get the accurate
> lastAddConfirmed  from the open ledgers.
>
>
>
> Please let me know your thoughts.
>
>
>
> Regards,
>
>    Vinayakumar B.,
>
>    9538828765
>
>
>
>

Reply via email to