[jira] Commented: (HBASE-2027) HConnectionManager.HBASE_INSTANCES leaks TableServers

["stack (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785514#action_12785514 ] 

stack commented on HBASE-2027:
------------------------------

Your simpler bounded count of instances sounds good to me.  Ten should be more than enough.  You could make it configurable without adding the config. to hbase-default.xml; fellas would have to read the code to figure that they could change the value.   Its a static context though when this stuff is being set.  I'd say the patch is good enough as is.  Unless you object, will commit. 

You know, set the max to 31.  ZK maximum connections from a host is default 30.  This way, users will hardly ever hit this hard-coded max.  They'll get complaint from zk instead (And 30 instances is still small potatoes).

Good on you Dave.

> HConnectionManager.HBASE_INSTANCES leaks TableServers
> -----------------------------------------------------
>
>                 Key: HBASE-2027
>                 URL: https://issues.apache.org/jira/browse/HBASE-2027
>             Project: Hadoop HBase
>          Issue Type: Bug
>    Affects Versions: 0.20.0
>            Reporter: Dave Latham
>            Assignee: Dave Latham
>             Fix For: 0.20.3, 0.21.0
>
>         Attachments: 2027-LRU.patch, 2027.patch
>
>
> HConnectionManager.HBASE_INSTANCES is a WeakHashMap from HBaseConfiguration to TableServers.  However, each TableServers has a strong reference back to the HBaseConfiguration key so they are never freed.  (See note at http://java.sun.com/javase/6/docs/api/java/util/WeakHashMap.html : "Implementation note: The value objects in a WeakHashMap are held by ordinary strong references. Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded.")
> Moreover, HBaseConfiguration implements hashCode() but not equals() so identical HBaseConfiguration objects each get their own TableServers object.
> We had a long running HBase client process that was creating new HTable() objects, each creating a new HBaseConfiguration() and thus a new TableServers object.  It eventually went OOM, and gave a heap dump indicating 360 MB of data retained by HBASE_INSTANCES.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.