Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase, mail # dev - Heads up, HTablePool will be deprecated in 0.94, 0.95/0.96, and removed in 0.98


Copy link to this message
-
Re: Heads up, HTablePool will be deprecated in 0.94, 0.95/0.96, and removed in 0.98
Ted Yu 2013-08-04, 03:52
Does this mean that user code wouldn't be able to depend
on HConnectionManager for connection sharing ?

If so, user may need to develop his / her own code for connection sharing ?

Cheers

On Sat, Aug 3, 2013 at 7:20 AM, Ted Yu <[EMAIL PROTECTED]> wrote:

> Ah, I find the JIRA - HBASE-9117.
>
> Cheers
>
>
> On Fri, Aug 2, 2013 at 10:54 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>
>> Yeah, I filed a separate ticket for the API removal in trunk.
>>
>>
>>
>> ________________________________
>>  From: Ted Yu <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
>> Sent: Friday, August 2, 2013 10:31 PM
>> Subject: Re: Heads up, HTablePool will be deprecated in 0.94, 0.95/0.96,
>> and removed in 0.98
>>
>>
>> bq. HConnectionManager.getConnection() will be removed.
>>
>> I don't see the above change in 6580-trunk.txt
>> Would the above be done in next patch or in another JIRA ?
>>
>> Cheers
>>
>> On Fri, Aug 2, 2013 at 9:29 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
>>
>> > See. https://issues.apache.org/jira/browse/HBASE-6580
>> >
>> > The new proposed API looks like this:
>> >
>> > Here's the proposed new API:
>> > * HConnectionManager:
>> >     public static HConnection createConnection(Configuration conf)
>> >     public static HConnection createConnection(Configuration conf,
>> > ExecutorService pool)
>> >
>> > * HConnection:
>> >     public HTableInterface getTable(byte[] tableName) throws IOException
>> >     public HTableInterface getTable(byte[] tableName, ExecutorService
>> > pool) throws IOException
>> >     public HTableInterface getTable(String tableName) throws IOException
>> >
>> > By default HConnectionImplementation will create an ExecutorService when
>> > needed. The ExecutorService can optionally passed be passed in.
>> > HTableInterfaces are retrieved from the HConnection. By default the
>> > HConnection's ExecutorService is used, but optionally that can be
>> > overridden for each HTable.
>> >
>> > In 0.98/trunk:
>> >
>> > 1. HTablePool will be removed. It is not longer needed.
>> > 2. All constructors in HTable will be removed and changed to be
>> protected.
>> > All code use HTableInterface only.
>> > 3. HConnectionManager.getConnection() will be removed.
>> > 3. All HConnection caching (deleteConnection, etc,etc) will be removed,
>> as
>> > it is no longer needed.
>> >
>> >
>> > The new flow of setting up a client would look like this:
>> >
>> > ----- Snip -----
>> > // connection to the cluster
>> > HConnection conn = HConnectionManager.createConnection(conf);
>> > ...
>> > // When the cluster connection is established get an HTableInterface for
>> > each operation or thread.
>> > // HConnection.getTable(...) is lightweight. The table is really just a
>> > convenient place to call table method and for a temporary batch cache.
>> > // It is in fact less overhead than HTablePool had when retrieving a
>> > cached HTable.
>> > // The HTableInterface returned is not thread safe as before.
>> > // It's fine to get 1000's of these.
>> > // Don't cache the longer than the lifetime of the HConnection
>> > HTableInterface table = conn.getTable("MyTable");
>> > ...
>> > // just flushes outstanding commit, no futher cleanup needed, can be
>> > omitted.
>> > // HConnection holds no references to the returned HTable objects, they
>> > can be GC'd as soon as they leave scope.
>> > table.close();
>> > ...
>> > conn.close(); // done with the cluster, release resources
>> > ----- Snip -----
>> >
>> > The HConnection will maintain and share its own ThreadPool for all batch
>> > operations executed by the HTables.
>> > This can overridden per HConnection and/or per individual HTable object.
>> >
>> > I will commit the new API to all branches early next week.
>> >
>> > Questions? Comments? Concerns? Praise?
>> >
>> > -- Lars
>>
>
>