Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 13 Dec 2012 05:37:24 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12603384.1344920663241.27116.1355377044005@arcas>
In-Reply-To: <JIRA.12603384.1344920663241@arcas>
References: <JIRA.12603384.1344920663241@arcas>
Subject: [jira] [Commented] (HBASE-6580) New HTable pool, based on
 HBase(byte[], HConnection, ExecutorService) constructor
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Hmm... {{HConnection.getTable(byte[], ExecutorService)}} is not that much better than {{new HTable(byte[], HConnection, ExecutorService)}}.

Note that a single HTable can use many threads to parallelize update requests to multiple region servers.

Let's do this?
* optionally allow createConnection to be passed a ExecutorService, I think we can document that this service will be closed when the connection is closed. If none is passed create the executor as you do (but maybe with more core threads that do not time out?).
* optionally allow getTable to override the ExecutorService.

(For example: In our case we'll have an ExecutorService with something like 100 core threads, a wait queue of size 100, and max size of 200... For a total of 300 outstanding update requests across all HTable instances).

                
> 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