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
Suraj Varma 2013-08-05, 20:21
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)
> >
>