hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Heads up, HTablePool will be deprecated in 0.94, 0.95/0.96, and removed in 0.98
Date Mon, 05 Aug 2013 22:17:27 GMT
+1 as well.

On Mon, Aug 5, 2013 at 2:30 PM, Enis Söztutar <enis.soz@gmail.com> wrote:

> +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 <svarma.ng@gmail.com> 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 <ghelmling@gmail.com>
> > 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 <apurtell@apache.org>
> > > 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 <stack@duboce.net> wrote:
> > > >
> > > > > On Sun, Aug 4, 2013 at 7:56 PM, lars hofhansl <larsh@apache.org>
> > > 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)
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message