hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lars Hofhansl (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6580) Deprecate HTablePool in favor of HConnection.getTable(...)
Date Fri, 02 Aug 2013 05:35:48 GMT

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

Lars Hofhansl commented on HBASE-6580:
--------------------------------------

bq. the difference between HCM#getConnection and HCM#createConnection is that the latter will
ALWAYS create a "cluster connection"? 

Yep. It also indicates that the caller needs to manage the lifecycle (i.e. eventually close()'ing
the connection).

Should probably deprecate HCM#getConnection as well.

bq. (How hard to change HTable into an Interface?)
HTable is the implementation of HTableInterface. The patch only exposes HTableInterface.
Should we rename HTableInterface to HTable and HTable to HTableImplementation?

Oh, I see. You saying HTable should not have any public constructors? Can deprecate those
as well.

                
> Deprecate HTablePool in favor of HConnection.getTable(...)
> ----------------------------------------------------------
>
>                 Key: HBASE-6580
>                 URL: https://issues.apache.org/jira/browse/HBASE-6580
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.94.6, 0.95.0
>            Reporter: Lars Hofhansl
>            Assignee: Lars Hofhansl
>            Priority: Minor
>             Fix For: 0.98.0, 0.95.2, 0.94.11
>
>         Attachments: 6580-trunk.txt, HBASE-6580_v1.patch, HBASE-6580_v2.patch
>
>
> Update:
> I now propose deprecating HTablePool and instead introduce a getTable method on HConnection
and allow HConnection to manage the ThreadPool.
> Initial proposal:
> 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

Mime
View raw message