[
https://issues.apache.org/jira/browse/HBASE-19543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-19543:
------------------------------
Attachment: HBASE-19543-HBASE-19397-v3.patch
Fix checkstyle, javadoc and UT issues.
One of the checkstyle issue is method too long for HMaster, which is not easy
to fix so left it there. And the failed UT is because we will throw exception
if you want to enable an already enabled replication peer. So just remove the
extra enablePeer call at the beginning of the test.
> Abstract a replication storage interface to extract the zk specific code
> ------------------------------------------------------------------------
>
> Key: HBASE-19543
> URL: https://issues.apache.org/jira/browse/HBASE-19543
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2, Replication
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Attachments: HBASE-19543-HBASE-19397-v1.patch,
> HBASE-19543-HBASE-19397-v2.patch, HBASE-19543-HBASE-19397-v3.patch,
> HBASE-19543-HBASE-19397.patch, HBASE-19543-HBASE-19397.patch
>
>
> For now, we will do sanity checks at the same time when updating replication
> peer. But this is not a safe way for procedure based replication peer
> modification.
> For the old zk watcher way, the only thing is updating the data on zk, so if
> the data is updated and then we crashes, there is no problem.
> For the new procedure way, we need to trigger refresh by ourselves after
> updating zk. If we crashes after the updating and before we record the state
> change of the procedure, we may fail with IllegalArgumentException when we
> execute the procedure next time since the data on zk has already been updated.
> So the current way is to do sanity checks in PRE_PEER_MODIFICATION state, and
> in UPDATE_STORAGE state we will not do sanity checks any more, just
> update(overwrite) the peer storage.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
