[
https://issues.apache.org/jira/browse/HBASE-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12906429#action_12906429
]
Robert Mahfoud commented on HBASE-2925:
---------------------------------------
You may have left out a couple of print statements in TestHCM. Not sure if that
was intentional.
{code}
System.out.println("Hash Code: " + configuration.hashCode());
...
System.out.println("!! Got same connection for once !!");
{code}
Otherwise it's good to go.
> 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.
