[
https://issues.apache.org/jira/browse/HBASE-6580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508252#comment-13508252
]
Adrian Muraru commented on HBASE-6580:
--------------------------------------
Lars, you're right, having a way to pass an already fine tuned executor is
useful such cases. building one from configuration params might not be enough.
Thinking of this, I'm more in favour of adding executor param to #getTable In
order to Alloa mixt workloads to share the HConnection placement info
ExecutorService lowPriority=....
ExecutorService highPriority=....
HC conn= HCM.createConnection()
conn.getTable(table1, lowPriority)
conn.getTable(table2, highPriority)
+1 removing HTablePool
+1 removing managed HConnections - is this doable? Do we use it elsewhere?
+1 keep only lightweight HTable ctors
> 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
