[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enrico Olivelli resolved BOOKKEEPER-1037.
-----------------------------------------
    Resolution: Won't Fix

[~hustlmsp] you are right.

I was writing some Test Case inside the BookKeeper codebase in order to prove 
my problem and I have found an answer to my own problem.

I had a silly bug in the recovery code or a new project which skipped the 
recovery in case of LastAddConfirmed = 0.

If the writer writes only one entry and crashes after the recovery the 
LastAddConfirmed will be 0, and so my bug of the "lost write".

I was very worried because I have been using BooKeeper for much time and I did 
not ever get that issue.

In fact it was a bug of my new code !

I will delete the BP7 page as it is not useful and sounds like spam if you are 
OK

> BP7 - Explicit LAC on addEntry
> ------------------------------
>
>                 Key: BOOKKEEPER-1037
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-1037
>             Project: Bookkeeper
>          Issue Type: New Feature
>          Components: bookkeeper-client, bookkeeper-server
>    Affects Versions: 4.4.0
>            Reporter: Enrico Olivelli
>            Assignee: Enrico Olivelli
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> see 
> https://cwiki.apache.org/confluence/display/BOOKKEEPER/BP7+-+Explicit+LAC+on+addEntry
> Summary of the problem:
> We want to ensure that some "important" entries will be readable for which 
> the writer has received the acknowledge from a quorum of bookies without 
> being able to piggyback the LastAddConfirmed or close the LedgerHandle (a 
> writer which crashes).
> This is the simplest failing scenario:
>     A writer creates a ledger
>     The writer adds and entry and blocks for the acknowldege of the 
> configured quorum of Bookies
>     The writer crashes
>     LAC has not been sent to Bookies and it has not been written to metadata
>     A recovery is performed, truncating the ledger to the maximum 
> LastAddConfirmed entry ID
>     Now the entry is no more readable and there is no trace of it on metadata 
> so it cannot be recovered
> We can add a new BookKeeper function, addConfirmedEntry  which acks like the 
> addEntry function but sends on the protocol a new flag which tells to the 
> Bookie to "advance" the LastAddConfirmed flag immediately as we already do 
> with the ExplicitLAC.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to