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

Ted Yu commented on HBASE-3171:
-------------------------------

>From https://builds.apache.org/job/PreCommit-HBASE-Build/4722/consoleFull, one 
>test hung :
{code}
"pool-1-thread-1" prio=10 tid=0x77002400 nid=0x38bf sleeping[0x77466000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
        at java.lang.Thread.sleep(Native Method)
        at 
org.apache.hadoop.hbase.TestDrainingServer.waitForAllRegionsOnline(TestDrainingServer.java:268)
        at 
org.apache.hadoop.hbase.TestDrainingServer.setUpBeforeClass(TestDrainingServer.java:81)
{code}
                
> Drop ROOT and instead store META location(s) directly in ZooKeeper
> ------------------------------------------------------------------
>
>                 Key: HBASE-3171
>                 URL: https://issues.apache.org/jira/browse/HBASE-3171
>             Project: HBase
>          Issue Type: Improvement
>          Components: Client, master, regionserver, Zookeeper
>            Reporter: Jonathan Gray
>         Attachments: HBASE-3171.patch, HBASE-3171-v2.patch, 
> HBASE-3171-v3.patch, HBASE-3171-v4.patch, HBASE-3171-v5.patch, 
> HBASE-3171-v6.patch, HBASE-3171-v7.patch
>
>
> Rather than storing the ROOT region location in ZooKeeper, going to ROOT, and 
> reading the META location, we should just store the META location directly in 
> ZooKeeper.
> The purpose of the root region from the bigtable paper was to support 
> multiple meta regions.  Currently, we explicitly only support a single meta 
> region, so the translation from our current code of a single root location to 
> a single meta location will be very simple.  Long-term, it seems reasonable 
> that we could store several meta region locations in ZK.  There's been some 
> discussion in HBASE-1755 about actually moving META into ZK, but I think this 
> jira is a good step towards taking some of the complexity out of how we have 
> to deal with catalog tables everywhere.
> As-is, a new client already requires ZK to get the root location, so this 
> would not change those requirements in any way.
> The primary motivation for this is to simplify things like CatalogTracker.  
> The way we can handle root in that class is really simple but the tracking of 
> meta is difficulty and a bit hacky.  This hack on tracking of the meta 
> location is what caused one of the bugs over in HBASE-3159.

--
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

Reply via email to