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 (Commented) (JIRA)" <ji...@apache.org> on 2011/11/17 05:06:51 UTC
[jira] [Commented] (HBASE-4805) Allow better control of resource
consumption in HTable
[ https://issues.apache.org/jira/browse/HBASE-4805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13151778#comment-13151778 ]
stack commented on HBASE-4805:
------------------------------
I prefer the previous formatting (for the next time):
{code}
- public HTable(Configuration conf, final String tableName)
- throws IOException {
+ public HTable(Configuration conf, final String tableName) throws IOException {
this(conf, Bytes.toBytes(tableName));
{code}
(and its < 80 chars on a line).
Nice javadoc on the HTable constructor.
Don't you need to javadoc that conf has to be null if you pass a connection and pool else they'll not be used?
Hmmm... maybe its better to not take a conf at all? Else it could get confusing. Say you'll use the configuration that is in the passed HConnection? Looking at the way this new constructor runs, I could really mess w/ you passing null Configuration and null Connection. More checks I'd say.
Else patch looks good to me and +1 on getting it into 0.92.
> Allow better control of resource consumption in HTable
> ------------------------------------------------------
>
> Key: HBASE-4805
> URL: https://issues.apache.org/jira/browse/HBASE-4805
> Project: HBase
> Issue Type: Bug
> Components: client
> Affects Versions: 0.92.0, 0.94.0
> Reporter: Lars Hofhansl
> Assignee: Lars Hofhansl
> Fix For: 0.94.0
>
> Attachments: 4805.txt
>
>
> From some internal discussions at Salesforce we concluded that we need better control over the resources (mostly threads) consumed by HTable when used in a AppServer with many client threads.
> Since HTable is not thread safe, the only options are cache them (in a custom thread local or using HTablePool) or to create them on-demand.
> I propose a simple change: Add a new constructor to HTable that takes an optional ExecutorService and HConnection instance. That would make HTable a pretty lightweight object and we would manage the ES and HC separately.
> I'll upload a patch a soon to get some feedback.
--
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