You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Hudson (JIRA)" <ji...@apache.org> on 2018/03/09 21:03:02 UTC
[jira] [Commented] (HBASE-19216) Implement a general framework to
execute remote procedure on RS
[ https://issues.apache.org/jira/browse/HBASE-19216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16393547#comment-16393547 ]
Hudson commented on HBASE-19216:
--------------------------------
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.
> Implement a general framework to execute remote procedure on RS
> ---------------------------------------------------------------
>
> Key: HBASE-19216
> URL: https://issues.apache.org/jira/browse/HBASE-19216
> 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-19216-v1.patch, HBASE-19216-v2.patch, HBASE-19216.patch, HBASE-19216.patch, HBASE-19216.patch
>
>
> When building the basic framework for HBASE-19064, I found that the enable/disable peer is built upon the watcher of zk.
> The problem of using watcher is that, you do not know the exact time when all RSes in the cluster have done the change, it is a 'eventually done'.
> And for synchronous replication, when changing the state of a replication peer, we need to know the exact time as we can only enable read/write after that time. So I think we'd better use procedure to do this. Change the flag on zk, and then execute a procedure on all RSes to reload the flag from zk.
> Another benefit is that, after the change, zk will be mainly used as a storage, so it will be easy to implement another replication peer storage to replace zk so that we can reduce the dependency on zk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)