[
https://issues.apache.org/jira/browse/HBASE-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-2925.
--------------------------
Hadoop Flags: [Reviewed]
Fix Version/s: 0.90.0
Resolution: Fixed
@Robert Yeah I removed some, left others but also added asserts so tests should
fail is regression. Thanks for doing up the test. I just committed v2.
> 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
> Fix For: 0.90.0
>
> Attachments: 2925-v2.txt, 2925.txt,
> 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.
