[
https://issues.apache.org/jira/browse/HBASE-16835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15578087#comment-15578087
]
Duo Zhang commented on HBASE-16835:
-----------------------------------
{code:title=ClusterRegistry.java}
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();
@Override
void close();
}
{code}
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
(v6.3.4#6332)
