[
https://issues.apache.org/jira/browse/HBASE-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13547668#comment-13547668
]
Ted Yu commented on HBASE-7411:
-------------------------------
Interesting patch.
{code}
+ * to recreate the connection. This class bridges bridges curator and our
zk-management.
{code}
'bridges' is repeated.
{code}
+ WatcherSet doubleWatcher;
{code}
Since WatcherSet always contains two Watchers, should the class be called
DoubleWatcher ?
{code}
+ public synchronized ZooKeeper newZooKeeper(String connectString, int
sessionTimeout, Watcher curatorWatcher,
{code}
Wrap long line.
{code}
+ if (LOG.isDebugEnabled()) {
+ LOG.debug("Sending last zookeeper event to curator: " + lastEvent);
+ }
+ if (lastEvent != null) {
{code}
I think the log should be placed inside the if block (lastEvent != null)
{code}
+ static class ManagedZooKeeperFactory implements ZookeeperFactory {
{code}
The above class can be private, right ?
{code}
+ public void reconnect() throws IOException, InterruptedException {
+ zkFactory.close(); //we don't want to close the CuratorClient
+ connect();
{code}
reconnect() invokes two methods of ManagedZooKeeperFactory. Should reconnect()
delegate to a synchronized method, reconnect(), of ManagedZooKeeperFactory ?
{code}
+ public void close() throws InterruptedException {
+ if (this.curatorClient != null) {
+ this.curatorClient.close();
+ }
{code}
this.curatorClient should be set to null after the close() call.
> Use Netflix's Curator zookeeper library
> ---------------------------------------
>
> Key: HBASE-7411
> URL: https://issues.apache.org/jira/browse/HBASE-7411
> Project: HBase
> Issue Type: New Feature
> Components: Zookeeper
> Affects Versions: 0.96.0
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Attachments: hbase-7411_v0.patch
>
>
> We have mentioned using the Curator library
> (https://github.com/Netflix/curator) elsewhere but we can continue the
> discussion in this.
> The advantages for the curator lib over ours are the recipes. We have very
> similar retrying mechanism, and we don't need much of the nice client-API
> layer.
> We also have similar Listener interface, etc.
> I think we can decide on one of the following options:
> 1. Do not depend on curator. We have some of the recipes, and some custom
> recipes (ZKAssign, Leader election, etc already working, locks in HBASE-5991,
> etc). We can also copy / fork some code from there.
> 2. Replace all of our zk usage / connection management to curator. We may
> keep the current set of API's as a thin wrapper.
> 3. Use our own connection management / retry logic, and build a custom
> CuratorFramework implementation for the curator recipes. This will keep the
> current zk logic/code intact, and allow us to use curator-recipes as we see
> fit.
> 4. Allow both curator and our zk layer to manage the connection. We will
> still have 1 connection, but 2 abstraction layers sharing it. This is the
> easiest to implement, but a freak show?
> I have a patch for 4, and now prototyping 2 or 3 whichever will be less
> painful.
> Related issues:
> HBASE-5547
> HBASE-7305
> HBASE-7212
--
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
