[
https://issues.apache.org/jira/browse/HBASE-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13738559#comment-13738559
]
Jean-Daniel Cryans commented on HBASE-9173:
-------------------------------------------
bq. Waiting for PeerStateTracker to receive the event doesn't necessarily
guarantee that all region servers have seen the event yet
Very true, it's also a problem when you add/remove a peer, but my concern here
was more centered on the client so at least if you enable a peer, then read the
state right after, that you see it as enabled. We know the write to the znode
went through.
I think keeping both ways to read, from cache and from zk, is the way to go.
> replication_admin#get_peer_state(id) in ruby script pointing to undefined
> method `getPeerState'
> -----------------------------------------------------------------------------------------------
>
> Key: HBASE-9173
> URL: https://issues.apache.org/jira/browse/HBASE-9173
> Project: HBase
> Issue Type: Bug
> Components: scripts
> Reporter: rajeshbabu
> Assignee: Jean-Daniel Cryans
> Priority: Critical
> Fix For: 0.98.0, 0.95.2
>
> Attachments: HBASE-9173.patch
>
>
> list_peers is failing because replication_admin#get_peer_state(id) pointing
> to the method removed from ReplicationAdmin. We need to read peer state from
> ReplicationPeer.
> {code}
> hbase(main):003:0> list_peers
> PEER_ID CLUSTER_KEY STATE
> ERROR: undefined method `getPeerState' for
> #<Java::OrgApacheHadoopHbaseClientReplication::ReplicationAdmin:0x7e299629>
> Here is some help for this command:
> List all replication peer clusters.
> hbase> list_peers
> {code}
> {code}
> # Get peer cluster state
> def get_peer_state(id)
> @replication_admin.getPeerState(id)
> end
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
