[
https://issues.apache.org/jira/browse/BOOKKEEPER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400727#comment-13400727
]
Ivan Kelly commented on BOOKKEEPER-246:
---------------------------------------
{quote}
This delete call can fail with NodeNotEMpty exception as, lock file will
present inside that.
{quote}
The locks are created under the urLockPath, not urLedgerPath. This has two
advantages. 1. we can just delete the ledger znode without worrying. 2. the
ledger znodes can be moved to another metadata store, without affecting the
locks. This could be important for BOOKKEEPER-181.
{quote}
I was written most of this node fetching code in Replication wroker. I like
this abstraction. Implemented the Lock in separate class and make use of it.
Already filed a JIRA BOOKKEEPER-305
{quote}
Do you have a patch for BOOKKEEPER-305?
{quote}
As per my understanding Rakesh is trying to update the multiple bookie failure
to the same ledger under replicated Znode with some data, ex: BKIP:port1,
BKIP:port2. SO, that current replication should check the version number for
deleting the ledger znode. otherwise we may end up deleting that znode right?
{quote}
This is something I hadn't considered. This can be implemented within the
LedgerUnderreplicationManager without needing to change the API. Instead of
storing just the lock znode in the heldLock map, I can store the stat also.
Then when I try to markLedgerComplete, i can pass the stat.getVersion() to the
delete to make sure if another bookie has failed, another recover will take
place.
{quote}
markLedgerUnderreplicated api will be used by Auditor.
getLedgerToRereplicate & markLedgerComplete apis will be used by
ReplicationWorker right?
{quote}
Exactly.
> Recording of underreplication of ledger entries
> -----------------------------------------------
>
> Key: BOOKKEEPER-246
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-246
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Ivan Kelly
> Assignee: Ivan Kelly
> Fix For: 4.2.0
>
> Attachments: BOOKKEEPER-246.diff
>
>
> This JIRA is to decide how to record that entries in a ledger are
> underreplicated.
> I think there is a common understanding (correct me if im wrong), that
> rereplication can be broken into two logically distinct phases. A) Detection
> of entry underreplication & B) Rereplication.
> This subtask is to handle the interaction between these two stages. Stage B
> needs to know what to rereplicate; how should Stage A inform it?
--
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
