[
https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-6322.
--
Resolution: Fixed
Fix Version/s: 0.92.2
Hadoop Flags: Reviewed
Applied to 0.92. Thanks for the patch Ryan. Do we need something like this on
0.94 and trunk too?
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
