[jira] [Commented] (BOOKKEEPER-208) Separate write quorum from ack quorum

["Sijie Guo (JIRA)" <ji...@apache.org>]

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

Sijie Guo commented on BOOKKEEPER-208:
--------------------------------------

the latest patch looks good to me. +1.

since that it changed the client, I think it would be better to change hedwig too, to let it use the latest api so user could configure writeQuorumSize and ackQuorumSize. It would be a separated jira. I would create one to do it.
                
> Separate write quorum from ack quorum
> -------------------------------------
>
>                 Key: BOOKKEEPER-208
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-208
>             Project: Bookkeeper
>          Issue Type: New Feature
>          Components: bookkeeper-client
>            Reporter: Flavio Junqueira
>            Assignee: Ivan Kelly
>             Fix For: 4.2.0
>
>         Attachments: BOOKKEEPER-208.diff, BOOKKEEPER-208.diff, BOOKKEEPER-208.diff, BOOKKEEPER-208.diff, BOOKKEEPER-208.diff, BOOKKEEPER-208.diff
>
>
> There are use cases for bookkeeper that may require submitting add requests to a write set and returning upon receiving a confirmation from an ack set. The ack set must be a subset of the write set. An important special case is writing to all and returning upon hearing from a majority. Another important use case is avoiding *s* slow disks by writing to *f + s + 1* and returning upon receiving *f + 1* responses.
> Currently, the write set and the ack set are the same for a ledger. Internal changes to support these cases include changes to LedgerHandle and PendingAddOp. We also need to add a call to the client API to accept different sizes for the write set and the ack set upon ledger creation.
> It is also open for the discussion the need to implement a new distribution schedule. So far it looks like we can reuse the round robin implementation we currently have. We would need to implement a new one if, for example, the initial bookie of an add operation must be always the same.

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