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
+1 on making the connection API explicit.

We should start dog-fooding, and actively encouraging the new usage in 0.96
(can come after 0.96.0)

Enis
On Mon, Aug 5, 2013 at 1:21 PM, Suraj Varma <[EMAIL PROTECTED]> wrote:

> Might this be a good time to _not_ throw IOException and perhaps throw
> something along the lines of retryable / non-retryable etc exceptions -
> similar to the hierarchy in asynchbase?
>
> Since clients have to change anyways ... perhaps it is a good time to
> introduce this change?
> --S
>
>
> On Mon, Aug 5, 2013 at 10:45 AM, Gary Helmling <[EMAIL PROTECTED]>
> wrote:
>
> > +1
> >
> > Nice work on this Lars!
> >
> > This will make the client connection code a lot simpler and a lot easier
> to
> > reason about.
> >
> > While it's unfortunate that external client code will necessarily need to
> > be reworked for the changes, I think the result will be much cleaner all
> > around.  It will be great to get rid of the convolutions of HTablePool as
> > well.  If necessary to ease the client transition, HTablePool could even
> be
> > kept, but reworked as just a simple wrapper around HConnection (no need
> to
> > even do reference counting, etc).
> >
> > Looking forward to start making use of this.
> >
> > --gh
> >
> >
> > On Mon, Aug 5, 2013 at 10:31 AM, Andrew Purtell <[EMAIL PROTECTED]>
> > wrote:
> >
> > > +1 Lars
> > >
> > > I think it makes sense to take your experience with using the client in
> > app
> > > servers into API improvements.
> > >
> > > > Love the quiz.
> > >
> > > +1 nice illustration
> > >
> > > On Mon, Aug 5, 2013 at 8:25 AM, Stack <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Sun, Aug 4, 2013 at 7:56 PM, lars hofhansl <[EMAIL PROTECTED]>
> > wrote:
> > > >
> > > > > Let's do a little quiz:
> > > > >
> > > > > HTable t1 = new HTable(conf);
> > > > > t1.close();
> > > > >
> > > > > // 1. Will the next line create a new HConnection behind the scenes
> > > > (along
> > > > > with re-creating all the caches)?
> > > > > // (If so, it will be expensive, if not, when is the first
> > HConnection
> > > > > actually released?)
> > > > > HTable t2 = new HTable(conf);
> > > > >
> > > > > // 2. how about this one?
> > > > > HTable t2 = new HTable(new Configuration(conf));
> > > > >
> > > > > // 3. or now?
> > > > > conf.setInt(HConstants.HBASE_CLIENT_PAUSE, 2000);
> > > > > HTable t3 = new HTable(conf);
> > > > >
> > > > > // 4. and now?
> > > > > conf.setInt(HBASE_CLIENT_SCANNER_MAX_RESULT_SIZE_KEY, 1024000);
> > > > > HTable t4 = new HTable(conf);
> > > > >
> > > > > // 5. how many connections are opened now?
> > > > > t4.close();
> > > > >
> > > > > This stuff is convoluted and needlessly complicated. And this is
> not
> > > > > because the code is bad, but because the abstraction is simply
> > > > inadequate.
> > > > > A client wants to connect to a cluster and then do some action on
> > that
> > > > > cluster (via HTable as a convenience).
> > > > > If the cluster connection is implicit it leads to all of the above
> > > > > considerations.
> > > > >
> > > > >
> > > > Love the quiz.
> > > >
> > > > +1 on your redo of our connection model (HConnection is a "cluster
> > > > connection".  I like that you have to get one of these first...)
> > > >
> > > > St.Ack
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > >    - Andy
> > >
> > > Problems worthy of attack prove their worth by hitting back. - Piet
> Hein
> > > (via Tom White)
> > >
> >
>