[
https://issues.apache.org/jira/browse/HBASE-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-2925:
-------------------------
Attachment: 2925-v2.txt
This version of the patch just adds javadoc to HTable explaining the advantage
of shared Configuration -- the sharing of zookeeper connection, cache of region
locations, etc.
If you have a minute, give it a gander Robert and if its good w/ you, I'll go
ahead and commit.
> 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: 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.
