+1 as well. On Mon, Aug 5, 2013 at 2:30 PM, Enis Söztutar <enis....@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...@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 <ghelml...@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 <apurt...@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 <st...@duboce.net> wrote: > > > > > > > > > On Sun, Aug 4, 2013 at 7:56 PM, lars hofhansl <la...@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) > > > > > > > > > >
