[rest] publish endpoint and statistics into ZooKeeper

Review Request #1039 - Created Oct. 18, 2010 and updated

Andrew Purtell
old-hbase
HBASE-3119
hbase
This change allows the REST interface to publish its endpoint and metrics, currently only requests/sec, into ZooKeeper. By default a permanent znode tree is created as needed at /hbase/rest/status and Stargate instances create ephemeral children of this with names in the format <host>:<port>. The ephemeral znodes contain JSON serialized information about the instance, e.g.

  {"connector":{"host":"restserver.example.com","port":"8080"},"statistics":{"requests":"13"}}

The function of Stargate itself is not affected, except for one significant change: now if the ZooKeeper service is lost, the Stargate instances will abort along with the rest of HBase.


  1. 
      
  2. ZooKeeperWatcher from o.a.h.hbase does not do what we want and much that we don't. 
  3. 
      
  1. 
      
  2. do we want to migrate class-specific static config to those classes?
    1. There are statics for other daemon ports nearby. I was following this convention.
  3. where did DEFAULT_LISTEN_PORT go to? i am not seeing it removed?
  4. this looks clever, is it more generically useful to other parts of hbase?
    1. Other parts of HBase use ZKW methods to do this. I brought this in here to do the same without pulling in all of the behavior of ZKW I didn't want. 
    2. Which behaviors of ZKW are you referring to?  Hopefully this component is generally reusable (the new ZooKeeperWatcher) and could be used even in limited contexts.  Using it as the primary watcher and registering with it also helps when writing unit test.  You'd then use ZKUtil methods for this kind of stuff and inherit work done there.
      
      We are going to need one more level underneath ZKUtil or underlying ZKUtil that manages retry policies and such.  I'm going to target that for 0.92.  And if all our code uses these APIs then it will be easier to be consistent.
      
      The patch looks fine to me though so we can work at unifying later and not blocking you on this.
    3. It also forces u into good behavior, for example, by needing to pass it an Abortable on construction.
    4. One issue is the constructor creates or checks znodes that the REST interface should not care about. (I'm thinking ahead to when ZK ACLs are in use a bit maybe.) Also I wanted automatic retry behavior for setData but that is something for which a wrapper around ZKUtil method calls would work. 
      
      Unifying later should not be a big deal.
    5. Good point, totally agree.  That definitely does not belong in the ZKW constructor.  The first master should do it and that's it.  Filed HBASE-3123.
  5. redundant assignment?
  6. ditto on this one. i wonder if there might be an elegant way to retry or redo zk operations, but there might not be.
  7. is this better called startZooKeeperClient?
  8. does this mean that stats are only updated every minute by default?
  9. 
      
  1. 
      
  2. 
      
Loading...