[jira] [Commented] (HBASE-19633) Clean up the replication queues in the postPeerModification stage when removing a peer

["Hudson (JIRA)" <ji...@apache.org>]

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

Hudson commented on HBASE-19633:
--------------------------------

Results for branch branch-2
	[build #465 on builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/465/]: (x) *{color:red}-1 overall{color}*
----
details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/465//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/465//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/465//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Clean up the replication queues in the postPeerModification stage when removing a peer
> --------------------------------------------------------------------------------------
>
>                 Key: HBASE-19633
>                 URL: https://issues.apache.org/jira/browse/HBASE-19633
>             Project: HBase
>          Issue Type: Sub-task
>          Components: proc-v2, Replication
>            Reporter: Duo Zhang
>            Assignee: Duo Zhang
>            Priority: Major
>             Fix For: 3.0.0, 2.1.0
>
>         Attachments: HBASE-19633-HBASE-19397-v1.patch, HBASE-19633-HBASE-19397-v2.patch, HBASE-19633-HBASE-19397-v3.patch, HBASE-19633-HBASE-19397.patch
>
>
> In the previous implementation, we can not always cleanly remove all the replication queues when removing a peer since the removing work is done by RS and if an RS is crashed then some queues may left there forever. That's why we need to check if there are already some queues for a newly created peer since we may reuse the peer id and causes problem.
> With the new procedure based replication peer modification, I think we can do it cleanly. After the RefreshPeerProcedures are done on all RSes, we can make sure that no RS will create queue for this peer again, then we can iterate over all the queues for all Rses and do another round of clean up.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)