[
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
