[
https://issues.apache.org/jira/browse/HBASE-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13738492#comment-13738492
]
Chris Trezzo commented on HBASE-9173:
-------------------------------------
Thinking about it a little more... if we have the two separate code paths like
above, then maybe we don't need the waitForStateChange method. If the client
reads directly from zookeeper, then they will see their own updates. Waiting
for PeerStateTracker to receive the event doesn't necessarily guarantee that
all region servers have seen the event yet, so I don't think it buys you much
if we have the separate client check.
Apologies if this is exactly what you were saying in your previous comment haha.
> 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
