[ 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)