Heya, We have long had the ambition to get away from ZooKeeper as the means by which a client interfaces with an HBase cluster. The ConnectionRegistry was introduced in 2.0 as part of the asynchronous client implementation [0], then called the ClusterRegistry. The name changed and a new implementation backed by an HMaster endpoint was introduced, called the MasterConnectionRegistry. That implementation was made more generic as the RpcConnectionRegistry, which can be backed by HMaster or RegionServer processes. Finally, many of the teething issues [1] with the RpcConnectionRegistry have been worked out. As of now, RpcConnectionRegistry is the default path for client cluster access on branch-3 [2].
With 2.6 upon us, we'd like to formalize the deprecation cycle for client implementations connecting to a cluster using the ZKConnectionRegistry. I have been using the RpcConnectionRegistry in several deployments since the 2.4 release line. In a deployment without using secured connections, it's a drop-in replacement. For secured deployments, it's simpler, because clients don't need to be granted ZooKeeper connection credentials. Movement of RPC burden from the ZooKeeper cluster to Region Servers is really nice for spreading out the load. Maybe others have deployed the feature as well and have some experience to report back? Based on my experience, I am in favor of marking ZKConnectionRegistry as Deprecated starting in 2.6 with a plan to remove it in 3.1 ... or 3.2 if necessary. What do you say? Any objections? Thanks, Nick [0]: https://issues.apache.org/jira/browse/HBASE-15921 [1]: https://issues.apache.org/jira/browse/HBASE-26149 [2]: https://issues.apache.org/jira/browse/HBASE-26174
