[
https://issues.apache.org/jira/browse/HBASE-19543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16299492#comment-16299492
]
Guanghao Zhang commented on HBASE-19543:
----------------------------------------
As we plan to add new storage interface, we can take more time to polish the
public methods in storage interface.
For interface ReplicationQueueStorage.
1. Can we use ServerName to replace old String(region server name)?
2. Add a addQueue method. The old impl use zk, so it add a new queue by call
ZKUtil.createWithParents when addLog.
3. Do we need removeReplicatorIfQueueIsEmpty? This can be done by the caller.
4. Do we need getAllWALs? This only used by cleaner.
5. Method name: use Log or WAL?
For interface ReplicationPeerStorage.
1. addReplicationPeer ==> addPeer. As the interface name is
ReplicationPeerStorage, so we can simplify the method name.
2. enablePeer, disablePeer, isPeerEnabled or setPeerState,getPeerState
3. Need javadoc for methods.
> 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.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)
