hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-1800) Too many ZK connections
Date Sun, 30 Aug 2009 17:53:32 GMT

    [ 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.


Mime
View raw message