[
https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508172#comment-13508172
]
Lars Hofhansl commented on HBASE-6580:
--------------------------------------
You will never be able to size the ExecutorService correctly without knowing
the app. This pool is used by all HTable instances using this Connection to
parallelize their requests to the RegionServers.
I'd rather have people think about it, rather than having a default that will
likely not be right for their use case.
Starting with single core thread is not right. There needs to be at least an
option to pass in a custom ExecutorService.
bq. I can do today: HTable t = new HTable(tableName,
HConnectionManager.getConnection(conf), pool)
You can do that, and it might even work for a bit :)
HConnectionManager.getConnection(...) is meant for cases where the connection
is created (and potentially cached) on behalf of an HTable.
I suppose that constructor should throw an exception is the connection is
managed.
This stuff is very confusing about our client.
Like HTablePool, HConnectionManager.getConnection should just go away.
> New HTable pool, based on HBase(byte[], HConnection, ExecutorService)
> constructor
> ---------------------------------------------------------------------------------
>
> Key: HBASE-6580
> URL: https://issues.apache.org/jira/browse/HBASE-6580
> Project: HBase
> Issue Type: Improvement
> Affects Versions: 0.92.2, 0.94.2
> Reporter: Lars Hofhansl
> Priority: Minor
> Attachments: HBASE-6580_v1.patch, HBASE-6580_v2.patch
>
>
> Here I propose a very simple TablePool.
> It could be called LightHTablePool (or something - if you have a better name).
> Internally it would maintain an HConnection and an Executor service and each
> invocation of getTable(...) would create a new HTable and close() would just
> close it.
> In testing I find this more light weight than HTablePool and easier to
> monitor in terms of resources used.
> It would hardly be more than a few dozen lines of code.
--
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
