[jira] [Updated] (HBASE-6322) Unnecessary creation of finalizers in HTablePool
[ https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-6322: -- Fix Version/s: (was: 0.92.2) 0.92.3 > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-6322) Unnecessary creation of finalizers in HTablePool
[ https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-6322: - Attachment: HBASE-6322-trunk.1.patch What I applied to trunk. > 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 > 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
[jira] [Updated] (HBASE-6322) Unnecessary creation of finalizers in HTablePool
[ https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Brush updated HBASE-6322: -- Attachment: HBASE-6322-0.92.1.patch Simple patch that for the 0.92 branch to implement HTableInterface and remove the test that checks for HTable. > 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 > Attachments: HBASE-6322-0.92.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
[jira] [Updated] (HBASE-6322) Unnecessary creation of finalizers in HTablePool
[ https://issues.apache.org/jira/browse/HBASE-6322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan Brush updated HBASE-6322: -- Description: >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. was: >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. > 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 > > 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
