[
https://issues.apache.org/jira/browse/BOOKKEEPER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398391#comment-13398391
]
Ivan Kelly commented on BOOKKEEPER-304:
---------------------------------------
{quote}
Just my idea is, during the bookie startup only one among them in the bkcluster
will play as auditor(do auditing service) and is part of the bookie server
side. With this approach I feel the recovery mechanism will act quickly on
failures.
Also Auditor recovery feature is a configurable item and can be switched
off/on. What's your thoughts on this?
{quote}
My understanding of it is that the auditor will run in the bookie process but
will not directly access any bookie internals. Instead it will do everything
through the client API. The reason for putting it in the same process it just
that it's more convenient. It could be moved to a different process if this
proves problematic.
{quote}
But I'm just thinking the overhead of generating the indexes each time. Will it
be ok?
{quote}
This is an open question. We'll have to run a couple of tests to verify, but to
start with, it should be ok.
> Prepare bookie vs ledgers cache and will be used by the Auditor
> ---------------------------------------------------------------
>
> Key: BOOKKEEPER-304
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-304
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-server
> Reporter: Rakesh R
> Assignee: Rakesh R
> Fix For: 4.2.0
>
> Attachments: BOOKKEEPER-304.1.patch
>
>
> This JIRA discusses how to build bookie -> ledgers cache and this will be
> used by the Auditor to publish the suspected ledgers of failed bookies.
--
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
