[
https://issues.apache.org/jira/browse/HBASE-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13181108#comment-13181108
]
Lars Hofhansl commented on HBASE-5084:
--------------------------------------
The difference is that with the
{code}
public HTable(final byte[] tableName, final HConnection connection,
final ExecutorService pool) throws IOException {
{code}
that I added in HBASE-4805 HTable will not need to do any cleanup.
It is by no means a big a deal, just that if ExecutorService is externally
managed while HConnection is not, we need to maintain more state in HTable in
order to do partial cleanup (close the - managed - HConnection, which decreases
its reference count, but leave the ExecutorService alone).
We can add this logic, but I feel we should not over-engineer this... More
variations lead to more bugs or unexpected behavior for new users.
In my fairy tale world HConnectionImplementation would have the ExecutorService
as well, and you'd get an HTable via HConnection.getHTable(<tableName>).
> Allow different HTable instances to share one ExecutorService
> -------------------------------------------------------------
>
> Key: HBASE-5084
> URL: https://issues.apache.org/jira/browse/HBASE-5084
> Project: HBase
> Issue Type: Task
> Reporter: Zhihong Yu
>
> This came out of Lily 1.1.1 release:
> Use a shared ExecutorService for all HTable instances, leading to better (or
> actual) thread reuse
--
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
