[
https://issues.apache.org/jira/browse/BOOKKEEPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293507#comment-13293507
]
Ivan Kelly commented on BOOKKEEPER-272:
---------------------------------------
{quote}
I have used the predecessor watching approach, used to avoid the herd effect
with zookeeper leader election. Rule is, bookie will be watching to my
predecessor bookie based on the ephemeral seq id. At any point of time, least
ephemeral znode bookie only will get the chance to become Auditor. So I thought
it would be more efficient to watch on my predecessor bookie. How does it sound?
{quote}
This is fine. I just thought having all watch for children changed would make
simpler code. I don't have a strong opinion on this though.
{quote}
Hope you meant, after the auditor election I'm keeping the auditor's myInfo to
the auditor election path(/ledgers/auditor/election). At present there is no
logic, I've just kept for debugging purpose only(using ZK znodes).
{quote}
Ok. Thats fine. Before releasing i'd like to convert the data stored in the
znode as a protobuf text serialization. I've already done a conversion of
ledger metadata but havent' generated a patch/jira yet. I've made these changes
to make moving between bk versions easier. This is fine as it is for now though.
{quote}
Here I'd like to keep the generate & publishing suspected ledgers before
entering to the waitForNotification(). Consider the scenario where the auditor
bookie(say BK1) has failed and new auditor(BK2) comes, he will not recieve any
notifications for the BK1 failures(from the available bookie's path).
{quote}
Yup, that sounds good.
> Provide automatic mechanism to know bookie failures
> ---------------------------------------------------
>
> Key: BOOKKEEPER-272
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-272
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-server
> Reporter: Rakesh R
> Assignee: Rakesh R
> Attachments: BOOKKEEPER-272.1.patch, BOOKKEEPER-272.2.patch,
> BOOKKEEPER-272.Auditor.patch
>
>
> The idea is to build automatic mechanism to find out the bookie failures.
> Setup the bookie failure notifications to start the re-replication process.
> There are multiple approaches to findout bookie failures. Please refer the
> documents attached in BookKeeper-237.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
