Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 22 Sep 2016 20:11:20 +0000 (UTC)
From: "Ashu Pachauri (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12982461.1466715756000.641994.1474575080671@Atlassian.JIRA>
In-Reply-To: <JIRA.12982461.1466715756000@Atlassian.JIRA>
References: <JIRA.12982461.1466715756000@Atlassian.JIRA> <JIRA.12982461.1466715756470@arcas>
Subject: [jira] [Commented] (HBASE-16096) Replication keeps accumulating
 znodes
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 22 Sep 2016 20:11:22 -0000


    [ https://issues.apache.org/jira/browse/HBASE-16096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15514351#comment-15514351 ] 

Ashu Pachauri commented on HBASE-16096:
---------------------------------------

[~appy] Yeah, you got it right. The test asks the ReplicationSourceManager to remove the peer but never cleans it up from the zookeeper. When I look at the patch now, I also notice that it does a couple steps in the add_peer  workflow also that are redundant. I can clean the test up, it should be a tiny change.

> Replication keeps accumulating znodes
> -------------------------------------
>
>                 Key: HBASE-16096
>                 URL: https://issues.apache.org/jira/browse/HBASE-16096
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 2.0.0, 1.2.0, 1.3.0
>            Reporter: Ashu Pachauri
>            Assignee: Joseph
>             Fix For: 2.0.0, 1.3.0, 1.4.0
>
>         Attachments: HBASE-16096-branch-1.patch, HBASE-16096.patch
>
>
> If there is an error while creating the replication source on adding the peer, the source if not added to the in memory list of sources but the replication peer is. 
> However, in such a scenario, when you remove the peer, it is deleted from zookeeper successfully but for removing the in memory list of peers, we wait for the corresponding sources to get deleted (which as we said don't exist because of error creating the source). 
> The problem here is the ordering of operations for adding/removing source and peer. 
> Modifying the code to always remove queues from the underlying storage, even if there exists no sources also requires a small refactoring of TableBasedReplicationQueuesImpl to not abort on removeQueues() of an empty queue


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)