[
https://issues.apache.org/jira/browse/HBASE-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899617#action_12899617
]
Robert Mahfoud commented on HBASE-2925:
---------------------------------------
The only fix I could think of is to clone the configuration before inserting in
the new {{TableServer}} in {{HBASE_INSTANCES}}. This way, LRU will work since
the key cannot be changed since no other object holds a reference to it.
This will add the overhead of creating a new {{HBaseConfiguration}} instance
with every connection, which is minimal if the cache works as it should.
> 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.
