[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13530419#comment-13530419
 ] 

Flavio Junqueira commented on BOOKKEEPER-365:
---------------------------------------------

Hey guys, I'm trying to catch up with all the updates. If I understand your 
patch, Sijie, you're making sure that we return NoSuchEntry when enough bookies 
say they don't know about a given entry. Your patch also performs this check 
using write and quorum sizes. If this is the case, it sounds reasonable to me.

I don't particularly like the example you used here, though:  

https://issues.apache.org/jira/browse/BOOKKEEPER-365?focusedCommentId=13529398&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13529398

If ack quorum size is 1, then we can't tolerate a single failure, consequently 
the example is not fault tolerant by definition. Replacing the bookie actually 
is the wrong thing to do, but I think it is a special case that we shouldn't 
take care of. 

I was actually wondering about warning users in the case they use such a value 
for ack quorums.
                
> Ledger will never recover if one of the quorum bookie is down forever and 
> others dont have entry
> ------------------------------------------------------------------------------------------------
>
>                 Key: BOOKKEEPER-365
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-365
>             Project: Bookkeeper
>          Issue Type: Bug
>    Affects Versions: 4.0.0, 4.1.0
>            Reporter: Sijie Guo
>            Assignee: Sijie Guo
>             Fix For: 4.2.0
>
>         Attachments: BOOKKEEPER-365.diff, BOOKKEEPER-365.diff
>
>
> As discussed in BOOKKEEPER-355, current fix to handle the below issue is not 
> correct. Need to find out new solution
> If some bookies of a quorum gone forever, some bookies of this quorum are 
> still alive but doesn't have that entry (NoSuchEntry or NoSuchLedger), then 
> the ledger doesn't have any evidence to recovery/close it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to