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

Sijie Guo commented on BOOKKEEPER-365:
--------------------------------------

{quote}
But on a recovery ledger handle, we can do all the recovery, and just update 
the ledger handle when we close. So why don't we do just that? We already have 
a ReadOnlyLedgerHandle. We can just block metadata updates for 
handleBookieFailure and that should solve the problem.
{quote}

yup. this is the idea fixing BOOKKEEPER-355, which the case 3) I described in 
previous comment.

for this jira, I tends to fix the issue caused by separating write_quorum_size 
and ack_quorum_size.

{quote}
It only ever gets NoSuchEntry. See PerChannelBookieClient.java. This should 
allow you to make your patch simpler
{quote}

You are right. I missed that part in PerChannelBookieClient.

{quote}
I'm unclear on what maxMissedReadsAllowed actually means.
{quote}

maxMissedReadsAllowed means the max number of NoSuchEntry reads happened in a 
quorum. if this number is larger than (write_quorum_size - ack_quorum_size), it 
means that the entry hasn't ack'ed successfully based on the guarantee provides 
by 'ack_quorum'.

 
                
> 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
>
>
> 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