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

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

@Dave Grand.  My uninformed notion is that the way this HBASE_INSTANCES stuff 
works is broke.  A static map will always be problematic.  I can understand 
that in the one JVM you might want differently configured connections but 
keying with the HBC instance seems off.  Table name might be better but then 
what if you wanted differently configured connections to the same table?  Would 
that even make sense?  Thanks for looking into this.

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

Reply via email to