[
https://issues.apache.org/jira/browse/BOOKKEEPER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112216#comment-13112216
]
dhruba borthakur commented on BOOKKEEPER-68:
--------------------------------------------
I am more inclined to say that for the use case of NN using BK, it makes sense
to make one of the standby namenodes to fail the recover-ledger api call
(rather than retrying inside the BK client). The standby namenode will go back
to ZK to see if a new namenode master has been selected, if not then the
standby namenode can retry.
Ivan: is there some other approach that you have in mind?
> Conditional setData
> -------------------
>
> Key: BOOKKEEPER-68
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-68
> Project: Bookkeeper
> Issue Type: Bug
> Reporter: Flavio Junqueira
> Assignee: Flavio Junqueira
> Attachments: BOOKKEEPER-68.patch
>
>
> The write to ZooKeeper to store ledger metadata when closing a ledger must be
> conditional, otherwise concurrent clients might end up writing in a way that
> the update of a client overwrites the update of the other.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
