hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Antonov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4495) CatalogTracker has an identity crisis; needs to be cut-back in scope
Date Tue, 15 Jul 2014 01:02:49 GMT

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

Mikhail Antonov commented on HBASE-4495:

Old code wanted to loop with 100ms interval up until meta becomes available (as javadocs suggests
that null being returned is indication that meta isn't available), but when NotAllMetaRegionsOnlineException
exception is thrown, the loop is aborted. That code never really worked, I believe (need to
double check the history), as internal call to waitMetaRegionLocation() could never return
null - it throws this exception instead if meta isn't available.

> CatalogTracker has an identity crisis; needs to be cut-back in scope
> --------------------------------------------------------------------
>                 Key: HBASE-4495
>                 URL: https://issues.apache.org/jira/browse/HBASE-4495
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.94.0
>            Reporter: stack
>            Assignee: Mikhail Antonov
>              Labels: 1.0.0
>             Fix For: 0.99.0, 2.0.0
>         Attachments: HBASE-4495-v2.patch, HBASE-4495-v3.patch, HBASE-4495-v5.patch, HBASE-4495-v5.patch,
HBASE-4495-v6.patch, HBASE-4495-v7.patch, HBASE-4495-v7.patch, HBASE-4495.patch, HBASE-4495.patch,
HBASE-4495.patch, HBASE-4495.patch, HBASE-4495_(ADDENDUM-2).patch, hbase-4495_addendum.patch
> CT needs a good reworking.  I'd suggest its scope be cut way down to only deal in zk
transactions rather than zk and reading meta location in hbase (over an HConnection) and being
a purveyor of HRegionInterfaces on meta and root servers and being an Abortable and a verifier
of catalog locations.  Once this is done, I would suggest it then better belongs over under
the zk package and that the Meta* classes then move to client package.
> Here's some messy notes I added to head of CT class in hbase-3446 where I spent some
time trying to make out what it was CT did.
> {code}
>   // TODO: This class needs a rethink.  The original intent was that it would be
>   // the one-stop-shop for root and meta locations and that it would get this
>   // info from reading and watching zk state.  The class was to be used by
>   // servers when they needed to know of root and meta movement but also by
>   // client-side (inside in HTable) so rather than figure root and meta
>   // locations on fault, the client would instead get notifications out of zk.
>   // 
>   // But this original intent is frustrated by the fact that this class has to
>   // read an hbase table, the -ROOT- table, to figure out the .META. region
>   // location which means we depend on an HConnection.  HConnection will do
>   // retrying but also, it has its own mechanism for finding root and meta
>   // locations (and for 'verifying'; it tries the location and if it fails, does
>   // new lookup, etc.).  So, at least for now, HConnection (or HTable) can't
>   // have a CT since CT needs a HConnection (Even then, do want HT to have a CT?
>   // For HT keep up a session with ZK?  Rather, shouldn't we do like asynchbase
>   // where we'd open a connection to zk, read what we need then let the
>   // connection go?).  The 'fix' is make it so both root and meta addresses
>   // are wholey up in zk -- not in zk (root) -- and in an hbase table (meta).
>   //
>   // But even then, this class does 'verification' of the location and it does
>   // this by making a call over an HConnection (which will do its own root
>   // and meta lookups).  Isn't this verification 'useless' since when we
>   // return, whatever is dependent on the result of this call then needs to
>   // use HConnection; what we have verified may change in meantime (HConnection
>   // uses the CT primitives, the root and meta trackers finding root locations).
>   //
>   // When meta is moved to zk, this class may make more sense.  In the
>   // meantime, it does not cohere.  It should just watch meta and root and
>   // NOT do verification -- let that be out in HConnection since its going to
>   // be done there ultimately anyways.
>   //
>   // This class has spread throughout the codebase.  It needs to be reigned in.
>   // This class should be used server-side only, even if we move meta location
>   // up into zk.  Currently its used over in the client package. Its used in
>   // MetaReader and MetaEditor classes usually just to get the Configuration
>   // its using (It does this indirectly by asking its HConnection for its
>   // Configuration and even then this is just used to get an HConnection out on
>   // the other end). St.Ack 10/23/2011.
>   //
> {code}

This message was sent by Atlassian JIRA

View raw message