[ https://issues.apache.org/jira/browse/HBASE-4495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mikhail Antonov updated HBASE-4495: ----------------------------------- Attachment: HBASE-4495.patch Attacked is really just a sketchy patch to maybe get initial feedback (apologize for the size, but this CT is widespread). I expect a good portion of this patch to go away or be reworked after reviews. Key changes and points to discuss: - removed CT class and ported some logic pertaining to it into MetaRegionTracker - As described above, MetaRegionTracker was subclassing ZooKeeperNodeTracker - i.e. watcher - class needlessly (as all actual lookups were not against the cached znode value, but to actual ZK quorum even from the server side - and on client side we, as discussed, don't want to set watchers). So, renamed it to MetaRegionLocator. - during this work..here's the thing to discuss, almost always what we need is HConnection instance to the server and/or instance of ZooKeeperWatcher, which is something i want to get rid of, eventually, but here I had to actually pass it around to make it available in the meta lookups. Hope we can simplify it a lot if meta lookups are made thru MasterProto rpc calls. - Also, as part of this rework, I made the MetaRegionLocator to mostly be static util class, so it doesn't actually have lifecycle (not sure whether it's good idea to have lifecycle about logic like -getting meta location, if we don't use ZK watchers. getting location is stateless call, right?). Feedback appreciated. - in light of this effort above, I removed reference to CatalogTracker from Server interface, and instead added a method getShortCircuitConnection (as in quite a lot of places we're doing the lookups on server side where it's convenient to get short circuit connection directly from the server, and on client side - we just can get it using HConnectionManager.getConnection(conf)) - Removed MetaMigrationConvertingToPB class, as javadoc suggests it to be obsolete (this patch I actually extracted and posted under HBASE-11333, seems independent change..) - Merged together MetaReader and MetaEditor and called the result MetaTableAccessor. Something like that. Thinking that patch may (shall?) be broken down to smaller pieces, though they would be cross-dependent probably anyway. > 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 > Attachments: HBASE-4495.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 (v6.2#6252)