hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Daniel Cryans (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-546) Use Zookeeper in HBase
Date Tue, 25 Nov 2008 19:57:44 GMT

    [ https://issues.apache.org/jira/browse/HBASE-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650705#action_12650705
] 

Jean-Daniel Cryans commented on HBASE-546:
------------------------------------------

Review of that patch:

{quote}
<jdcryans> nitay: little reminder, lines must be < than 80 chars
<nitay> k
<jdcryans> nitay: in ZookeeperWrapper (let's call it ZKW), at line 76 there's a weird
char
<nitay> hehe ye u'r eright, no idea how that got in there
<jdcryans> yeah, was giving a javadoc warning
<jdcryans> in RegionManager, should we initializeZookeeper before reassignRootRegion?
<jdcryans> nitay: what do you think?
<nitay> looking
<jdcryans> also in RegionManager, I think writeRootRegionLocationToZooKeeper begs to
belong to ZKW
<nitay> ye i was gonna put it there only reason i didnt was cause i didnt want everyone
to have access to it
<nitay> and yes it makes sense to me that it be before reassignRootRegion
<jdcryans> yeah prevents race conditions IMO
<nitay> oh, explain please, im not seeing it
<nitay> what has a race condition
<jdcryans> if for some reason it takes a long time to connect to ZK, the connection
may not be ready when we assign the root region
<nitay> that's what waitForConnection is for
<nitay> ZooKeeper zooKeeper = zooKeeperWrapper.waitForZooKeeperConnection();
<nitay> now mind u, if we can't reach ZK, RM will block on this, inside its constructor,
right now
<nitay> i was seeing cases where ZK wasn't ready yet
<nitay> (particulaly b/c im on your old set of patches which run it last)
<jdcryans> hehe
<jdcryans> ok, but I would still put it before as a safety
<nitay> sure sounds good
<jdcryans> in the case we don't want to provide an access to writeRootRegionLocationToZooKeeper
(but in a way even if you don't have the method, you can still do it the same way it is done
in that method), I think you should provide a nicer method in ZKW to write into ZK
<jdcryans> or we would have that same code everywhere in hbase soon
<nitay> jdcryans: ok, that's a good point that the clients have raw access to the ZK
object, so yeah i'll move it into ZKW
<jdcryans> also it's more coherent with readRootRegionLocation
<jdcryans> but maybe we will still want a generic method to write into ZK.... we'll
see later when we add other features
<jdcryans> nitay: you will also be able to clean those imports
<nitay> right
<jdcryans> nitay:  ah but there is still that initializeZookeeper with lots of ZK stuff
in it...
<nitay> jdcryans: yeah i can make write do that stuff, its basically just making sure
the parent node exists
<nitay> which really shouldn't need to be done till the first write
<jdcryans> you mean adding a generic "write" method in ZKW?
<nitay> no i meant make writeRootRegionLocation create the parent node if it doesnt
exist
<nitay> rather than having the RM constructor make it
<jdcryans> ah ok good
<jdcryans> nitay: my last nitpick, why lazy instantiating ZKW in HCM? (wondering)
<nitay> ah hehe
<nitay> constructor doesn't throw
<nitay> so i figured instead of making it throw something new that all the users of
it would now have to handle, or making it do something sensible, i can just add on to the
method that uses it which already throws IOException
 nitay gives really long explanation for laziness?
<jdcryans> lol
<jdcryans> maybe just add that explanation in your code
<nitay> ok
{quote}

> Use Zookeeper in HBase
> ----------------------
>
>                 Key: HBASE-546
>                 URL: https://issues.apache.org/jira/browse/HBASE-546
>             Project: Hadoop HBase
>          Issue Type: Improvement
>            Reporter: Bryan Duxbury
>            Assignee: Jean-Daniel Cryans
>            Priority: Critical
>             Fix For: 0.20.0
>
>         Attachments: 0001-use-zookeeper-to-store-root-region-location.patch, DistributedLockInterface.java,
hbase-546-scripts-v2.patch, hbase-546-scripts.patch, zookeeper-config.patch
>
>
> Zookeeper =~ Chubby. This means that we could take advantage of a distributed lock manager
to coordinate things like failover masters, regionservers staying online when master is dead,
atomic region->regionserver assignments, etc. There are a lot of opportunities for improvements
here. Please add discussions of particular features in comments or sub-tasks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message