[
https://issues.apache.org/jira/browse/HBASE-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841320#comment-13841320
]
Jean-Marc Spaggiari commented on HBASE-10089:
---------------------------------------------
Looking at it, I don't really see the need for intern here...
There is only few tests over those variables.
+SchemaConfigured:+
cfName.equals(other.cfName) => Don't need intern for that test.
tableName.equals(other.tableName) => Don't need intern for that test
Sound like we never do cfName == something nor tableNames == something, except
for null.
+SchemaMetrics:+
The only place where it might be required. getBlockMetricName returns a
blockMetricNames[] cell where intern is used. Then addToCacheSize and others
call RegionMetricsStorage.incrTimeVaryingMetric, which
timeVaryingMetrics.get(key) where key is this blockMetricNames cell.
timeVaryingMetrics is a ConcurrentHashMap where the get is doing a hash of this
key, and another internal get. this final get is doing a key.equals(e.key) on
the key. So again, nowhere we have ==.
Am I missing something? If not, that mean we can "simply" remove the .intern()
calls.
I can quickly provide a patch for that if we want to try it. (No hadoop QA for
0.94, so we will have to manually test it).
> Metrics intern table names cause eventual permgen OOM in 0.94
> -------------------------------------------------------------
>
> Key: HBASE-10089
> URL: https://issues.apache.org/jira/browse/HBASE-10089
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.94.0, 0.94.14
> Reporter: Dave Latham
> Priority: Minor
>
> As part of the metrics system introduced in HBASE-4768 there are two places
> that hbase uses String interning ( SchemaConfigured and SchemaMetrics ).
> This includes interning table names. We have long running environment where
> we run regular integration tests on our application using hbase. Those tests
> create and drop tables with new names regularly. These leads to filling up
> the permgen with interned table names. Workaround is to periodically restart
> the region servers.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
