hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Rethinking the HBase client
Date Wed, 16 Nov 2011 22:13:04 GMT
On Wed, Nov 16, 2011 at 1:53 PM, lars hofhansl <lhofhansl@yahoo.com> wrote:
> The HConnection code itself seems clean, so ideally what we want to do is managing HConnections.
These are what identify and connect us to a cluster, and should drive everything.
>

Currently you can't get your hands directly on a particular
HConnection instance.  You have to do
HCM.getConnection(Configuration).  Wouldn't you want to change this
too -- i.e. not have HCM keep up an internal list?  Or at least have
the option to by-pass HCM accounting?

> HConnectionImplementation could have the thread pool on it that is shared by the various
HTables, and HTables could be created by a method on HConnection.
>

(Can we give this class a better name than HCI?  Smile)

You want to ask HCI to create an ExecutorService for batch operations?
   Would you want to pass it one so one ES for all HCIs in a hosting
service?

Having HConnection create HTables seems wrong.

HTable adds the retrying Callable stuff in it.

> So... An alternate (stop-gap) approach is to add a new constructor to HTable that allows
for an optional HConnection and a ThreadPool to be provided.


When you say ThreadPool, you mean ExecutorService?   The pool instance
in HTable?

This seems fine to me.


> Long term it seems a new client is needed (maybe based on asynchbase, with an additional
synchronous layer), but that is a different story.
>

Sounds good to me.

St.Ack

Mime
View raw message