[
https://issues.apache.org/jira/browse/BOOKKEEPER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13400527#comment-13400527
]
Uma Maheswara Rao G commented on BOOKKEEPER-246:
------------------------------------------------
-
{noformat}
@Override
+ public void markLedgerComplete(long ledgerId) throws
ReplicationException.UnavailableException {
+ try {
+ zkc.delete(getUrLedgerZnode(ledgerId), -1);
+ } catch (KeeperException.NoNodeException nne) {
{noformat}
This delete call can fail with NodeNotEMpty exception as, lock file will
present inside that.
-
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
-
Also other case while deleting ledger node is
When other peers trying to aquire the lock for same node also, they will create
one lock file, at the same time if the current node trying to delete the
ledgerNode, then also NotEmpty exception can come. On exception may be better
to call recursive delete api from ZKUtils?
-
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?
- One question:
markLedgerUnderreplicated api will be used by Auditor.
getLedgerToRereplicate & markLedgerComplete apis will be used by
ReplicationWorker right?
> 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
