You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2011/09/23 23:05:26 UTC

[jira] [Commented] (HBASE-4471) HTable.close() should shut down executor pool

    [ https://issues.apache.org/jira/browse/HBASE-4471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113765#comment-13113765 ] 

stack commented on HBASE-4471:
------------------------------

Not doing pool shutdown like a bug to me (If you look in 0.92, we seem to call pool shutdown -- where are you looking?)

> HTable.close() should shut down executor pool
> ---------------------------------------------
>
>                 Key: HBASE-4471
>                 URL: https://issues.apache.org/jira/browse/HBASE-4471
>             Project: HBase
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 0.90.3
>            Reporter: Josh Rosenblum
>
> Right now, it looks like HTable.close() is primarily concerned with flushing commits. I understand the intended semantics of close to be that clients should not attempt to call any other methods on that HTable instance after close is called. If that's true, then close() might leave around some relatively heavy resources after close() is called that can serve no further purpose. In particular, the executor this.pool may have a number of threads outstanding for some period of time (a minute with the default keepAliveTime of 60). With the default number of threads == the number of regionservers and with each thread having a 1mb stack by default on 64-bit jvms, this can be a considerable amount of memory left around (in addition to any other resources consumed by each thread). Is there any reason for close() not to also call this.pool.shutdown() after it calls flushCommits()?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira