[
https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093407#comment-16093407
]
Chia-Ping Tsai commented on HBASE-6322:
---------------------------------------
HTablePool doesn't exist. Close this issue?
> 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.3
>
> 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 was sent by Atlassian JIRA
(v6.4.14#64029)
