[ https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Zhihong Ted Yu reopened HBASE-6322: ----------------------------------- >From >https://builds.apache.org/view/G-L/view/HBase/job/HBase-0.92/466/testReport/org.apache.hadoop.hbase.rest/TestTableResource/testTableInfoText/: {code} java.lang.AssertionError: expected:<500> but was:<200> at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoText(TestTableResource.java:215) {code} The failure is reproducible locally. In the same test output you can see: {code} 2012-07-04 18:53:29,338 ERROR [2535725@qtp-29012646-0] log.Slf4jLog(87): /TestTableResource/regions java.lang.ClassCastException: org.apache.hadoop.hbase.client.HTablePool$PooledHTable cannot be cast to org.apache.hadoop.hbase.client.HTable {code} > Unnecessary creation of finalizers in HTablePool > ------------------------------------------------ > > Key: HBASE-6322 > URL: https://issues.apache.org/jira/browse/HBASE-6322 > Project: HBase > Issue Type: Bug > Components: client > Affects Versions: 0.92.0, 0.92.1, 0.94.0 > Reporter: Ryan Brush > Fix For: 0.92.2 > > Attachments: HBASE-6322-0.92.1.patch, HBASE-6322-trunk.1.patch > > > From a mailing list question: > While generating some load against a library that makes extensive use of > HTablePool in 0.92, I noticed that the largest heap consumer was > java.lang.ref.Finalizer. Digging in, I discovered that HTablePool's internal > PooledHTable extends HTable, which instantiates a ThreadPoolExecutor and > supporting objects every time a pooled HTable is retrieved. Since > ThreadPoolExecutor has a finalizer, it and its dependencies can't get garbage > collected until the finalizer runs. The result is by using HTablePool, we're > creating a ton of objects to be finalized that are stuck on the heap longer > than they should be, creating our largest source of pressure on the garbage > collector. It looks like this will also be a problem in 0.94 and trunk. > The easy fix is just to have PooledHTable implement HTableInterface (rather > than subclass HTable), but this does break a unit test that explicitly checks > that PooledHTable implements HTable -- I can only assume this test is there > for some historical passivity reason. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira