[
https://issues.apache.org/jira/browse/HBASE-1800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749295#action_12749295
]
stack commented on HBASE-1800:
------------------------------
Just to say that I do not like static maps. Inevitably they cause grief because
their initialization is effectively outside of your control done at
class-loading time. They become a problem when you want to reinit without a
restart of the jvm (e.g. deploy, undeploy, then redeploy of a web app that has
an HTable instance).
That said, we already have a static map of HCMs so you are coming in under its
cover. Lets fix both later. For 0.20.0, lets bring in this patch.
We also need to do the idea (I think it a Ryan idea from a while back) where
the hbase zk client is dumb doing read-only operations. Is this possible?
Does the client need to have watches in zk? (This again is for later).
Otherwise the patch looks good J-D. I'm +1 to commit assuming all unit tests
pass.
> 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,
> HBASE-1800-v3.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.
