[
https://issues.apache.org/jira/browse/HBASE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Daniel Cryans updated HBASE-1800:
--------------------------------------
Attachment: HBASE-1800-v2.patch
Different approach, I found that playing in the lower levels could mess when a
client would close a connection while sharing it with a region server and other
stuff like that.
In this patch:
- I created a new inner class called ClientZKWatcher in HCM that manages a
connection to ZK.
- I added a multiton of ClientZKWatcher keyed by hbase.zookeeper.quorum.
- I added a way to clear all connections.
> Too many ZK connections
> -----------------------
>
> Key: HBASE-1800
> URL: https://issues.apache.org/jira/browse/HBASE-1800
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: Jean-Daniel Cryans
> Fix For: 0.20.0, 0.21.0
>
> Attachments: HBASE-1800-v1.patch, HBASE-1800-v2.patch
>
>
> Currently we open tons of new connections to Zookeeper, like every time we
> instantiate a new HTable. There is a maximum number of client connections as
> described here:
> {code}
> <property>
> <name>hbase.zookeeper.property.maxClientCnxns</name>
> <value>30</value>
> <description>Property from ZooKeeper's config zoo.cfg.
> Limit on number of concurrent connections (at the socket level) that a
> single client, identified by IP address, may make to a single member of
> the ZooKeeper ensemble. Set high to avoid zk connection issues running
> standalone and pseudo-distributed.
> </description>
> </property>
> {code}
> If you hit that max number, ZK will just refuse your connections. Suppose you
> have 4 maps running on a server hosting a RS, you may actually lose your
> connection in the RS and eventually hit a session timeout. Maybe we should
> singleton ZKW?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
