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

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


+
lars hofhansl 2013-08-03, 04:29
+
Ted Yu 2013-08-03, 05:31
+
lars hofhansl 2013-08-03, 05:54
+
Ted Yu 2013-08-03, 14:20
+
Ted Yu 2013-08-04, 03:52
Copy link to this message
-
Re: Heads up, HTablePool will be deprecated in 0.94, 0.95/0.96, and removed in 0.98
Nick Dimiduk 2013-08-04, 03:56
On Sat, Aug 3, 2013 at 8:52 PM, Ted Yu <[EMAIL PROTECTED]> wrote:

> Does this mean that user code wouldn't be able to depend
> on HConnectionManager for connection sharing ?
>

My read of the above is that the HConnection instance is shared across
consumers, is the shared connection. Am I reading that correctly?

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
+
lars hofhansl 2013-08-04, 05:41
+
Ted Yu 2013-08-04, 23:27
+
lars hofhansl 2013-08-05, 02:23
+
Ted Yu 2013-08-05, 02:39
+
lars hofhansl 2013-08-05, 02:56
+
Stack 2013-08-05, 15:25
+
Andrew Purtell 2013-08-05, 17:31
+
Gary Helmling 2013-08-05, 17:45
+
Suraj Varma 2013-08-05, 20:21
+
Enis Söztutar 2013-08-05, 21:30
+
Ted Yu 2013-08-05, 22:17
+
Andrew Purtell 2013-08-06, 00:27
+
lars hofhansl 2013-08-06, 00:51
+
Ted Yu 2013-08-05, 03:08
+
lars hofhansl 2013-08-05, 03:32
+
Jesse Yates 2013-08-03, 06:50
+
Nick Dimiduk 2013-08-04, 03:20