hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HBASE-2925) LRU of HConnectionManager.HBASE_INSTANCES breaks if HBaseConfiguration is changed
Date Fri, 03 Sep 2010 03:00:34 GMT

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

stack commented on HBASE-2925:
------------------------------

@Robert What if we just removed the dump hash and equals and used object equality instead?
 I think it a bit much trying to equate Configuration objects; i.e. they are the same if they
have "same" config where "same" is every properties's hash equates.  If we were to go the
route of trying to equate Configurations by the properties they carry, we should equate the
values 'true', 'True', 'TRUE', and if a boolean !0 (anything but zero).

Thanks for filing this issue.

> LRU of HConnectionManager.HBASE_INSTANCES breaks if HBaseConfiguration is changed
> ---------------------------------------------------------------------------------
>
>                 Key: HBASE-2925
>                 URL: https://issues.apache.org/jira/browse/HBASE-2925
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.20.3, 0.90.0
>            Reporter: Robert Mahfoud
>         Attachments: SimpleHConnectionManagerLeakReplicator.java
>
>
> {{HConnectionManager.getConnection(config)}} caches the created {{TableServer}} in {{HBASE_INSTANCES}}
(a {{LinkedHashMap}} ) which is keyed by the configuration instance itself.
> Given the current implementation of {{hashCode()}} (and {{equals()}}) of {{HBaseConfiguration}},
the hash code of the configuration is changed if any of its properties are changed, which
will cause the keys of {{HBASE_INSTANCES}} to be inconsistent with the hashtable that contains
them, making some entries unreachable.
> In this case, when the map's LRU strategy needs to remove the oldest entry, it tries
to remove it based on the oldest key, which no longer gives the original hash code, therefore
the lookup in {{HBASE_INSTANCES.remove(oldest)}} doesn't actually remove anything.
> This has been observed to lead to OOM errors in long running clients.

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