[
https://issues.apache.org/jira/browse/HBASE-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236375#comment-13236375
]
stack commented on HBASE-5573:
------------------------------
This is radical in the ReplicationAdmin:
{code}
+ System.exit(1);
{code}
This is a client only? Maybe get the Abortable the this.connection is using?
Would that make sense?
Hmm... you do it in hbasefsck too.
Why not add a create method to ZooKeeperWatcher that takes a name, conf, and
Abortable? Or is that a ZKW Constructor altogether?
Creating the ZKW each time is probably expensive, takes time? But its ok in
ReplicationAdmin and in HBaseFSCK I would say?
In testing, do we want to rethrow what caused an abort? Perhaps rethrow as a
RuntimeException?
{code}
+ @Override public void abort(String why, Throwable e) {}
{code}
N, can you explain more about what is going on here. How is it that we are not
taking a Watcher when we are creating a ZKW? Because we don't call start?
(If so, that'd be 'elegant' solution)
> Replace client ZooKeeper watchers by simple ZooKeeper reads
> -----------------------------------------------------------
>
> Key: HBASE-5573
> URL: https://issues.apache.org/jira/browse/HBASE-5573
> Project: HBase
> Issue Type: Improvement
> Components: client, zookeeper
> Affects Versions: 0.96.0
> Reporter: nkeywal
> Assignee: nkeywal
> Priority: Minor
> Attachments: 5573.v1.patch, 5573.v2.patch, 5573.v4.patch,
> 5573.v6.patch
>
>
> Some code in the package needs to read data in ZK. This could be done by a
> simple read, but is actually implemented with a watcher. This holds ZK
> resources.
> Fixing this could also be an opportunity to remove the need for the client to
> provide the master address and port.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
