HBase
  1. HBase
  2. HBASE-4495

CatalogTracker has an identity crisis; needs to be cut-back in scope

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.94.0
    • Fix Version/s: 0.99.0, 2.0.0
    • Component/s: None
    • Labels:
    • Hadoop Flags:
      Reviewed

      Description

      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.

        // 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.
        //
      
      1. HBASE-4495_(ADDENDUM-2).patch
        5 kB
        Mikhail Antonov
      2. hbase-4495_addendum.patch
        0.7 kB
        Enis Soztutar
      3. HBASE-4495.patch
        434 kB
        stack
      4. HBASE-4495.patch
        434 kB
        Mikhail Antonov
      5. HBASE-4495.patch
        401 kB
        Mikhail Antonov
      6. HBASE-4495.patch
        401 kB
        Mikhail Antonov
      7. HBASE-4495-v2.patch
        435 kB
        Mikhail Antonov
      8. HBASE-4495-v3.patch
        433 kB
        Mikhail Antonov
      9. HBASE-4495-v5.patch
        492 kB
        stack
      10. HBASE-4495-v5.patch
        492 kB
        Mikhail Antonov
      11. HBASE-4495-v6.patch
        545 kB
        Mikhail Antonov
      12. HBASE-4495-v7.patch
        545 kB
        stack
      13. HBASE-4495-v7.patch
        545 kB
        Mikhail Antonov

        Issue Links

          Activity

            People

            • Assignee:
              Mikhail Antonov
              Reporter:
              stack
            • Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development