Duo Zhang commented on HBASE-16835:

interface ClusterRegistry extends Closeable {

  RegionLocations getMetaRegionLocation();

   * Should only be called once.
   * <p>
   * The upper layer should store this value somewhere as it will not be change 
any more.
  String getClusterId();

  int getCurrentNrHRS();

  ServerName getMasterAddress();

  int getMasterInfoPort();

  void close();

This is the original ClusterRegistry interface introduced in HBASE-15921. I 
added all the zk related operations needed at client side to it.

The getClusterId will only be called once when start up so it can be blocking 
and read directly from zk. And for getCurrentNrHRS, I think it is not very 
important so let's discuss it later. The getMasterInfoPort gets the same thing 
from zookeeper with getMasterAddress. So actually, the most important methods 
are getMetaRegionLocation and getMasterAddress.

For meta location, we will also cache it meta cache. And for master address, we 
have a logic to decide when to fetch the new address from zk. And usually, a 
client will cache all the region locations needed so it even does not need to 
know the meta location change as it will not access the meta table for a long 
time. And for master, it is also rarely touched from client. So I think it is 
reasonable to not rely on watcher to update the value as it may cause  
unnecessary network traffic.

But I think the API of meta cache and master address tracker should be changed. 
We have two timeouts right now, one for the normal operations, and the other 
one for the meta operations. I think we should have a larger timeout for meta 
operations because if we done then we could cache it. But in the old blocking 
world, it is a not a good idea to have a larger timeout in a sub stage... In 
the asynchronous world, we could return a CompletableFuture and use 
HashedWheelTimer to trigger timeout. So it is possible to have a larger timeout 
in a sub stage as upper layer has the ability to timeout before the actual 
process done.

> Revisit the zookeeper usage at client side
> ------------------------------------------
>                 Key: HBASE-16835
>                 URL: https://issues.apache.org/jira/browse/HBASE-16835
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Duo Zhang
> Watcher or not.
> Curator or not.
> Keep connection or not.
> ...

This message was sent by Atlassian JIRA

Reply via email to