>> even if we label it as an alpha initially for 0.92.0 With 0.90 stable release present, I doubt many people would want to try out an alpha 0.92 release.
My feeling about 0.92 release is ambivalent. On the one hand, I want to see the release of 0.92.0 since we have all put so much energy into it. On the other hand, I would like 0.92.0 to reach Beta quality. I suggest getting HBASE-5081 and HBASE-5120 into the next 0.92 RC. Cheers On Tue, Jan 3, 2012 at 7:45 PM, Todd Lipcon <[email protected]> wrote: > On Tue, Jan 3, 2012 at 7:40 PM, Ted Yu <[email protected]> wrote: > > I agree with Todd that we should cover the scenario where there're many > > regions. > > > >>> we at least have decent visibility and fix tools compared to what we > had > > in 90. > > We have better tools, yes. > > Would they solve the known / potential problems ? I don't think we have > > enough cases to prove that. > > Maybe not... but I don't think it's particularly worse off than 0.90.x > in this regard either. > > I won't vote +1 on the release since I haven't had time to pound on it > personally. But I generally think that we need to just get this thing > out there, even if we label it as an alpha initially for 0.92.0, beta > for 0.92.1, or whatever. Remember when we wanted to get 92 out for > Hadoop World? > > -Todd > > > > > On Tue, Jan 3, 2012 at 7:36 PM, Todd Lipcon <[email protected]> wrote: > > > >> On Tue, Jan 3, 2012 at 7:16 PM, Jean-Daniel Cryans <[email protected] > > > >> wrote: > >> > >> > I would also suggest a third option that seems like a stretch but > >> > could be workable: > >> > > >> > - MAX_FILESIZE is 4x bigger so users are less likely to have a huge > >> > number of regions (plus all our education), so the TM is less likely > >> > to cause damage and could be very useful. What I mean is 5119 could be > >> > committed but not 5120 for 0.92.0 > >> > > >> > >> That doesn't help the folks who will be upgrading from an existing > >> cluster and still have too-many regions. We've got some merge hacks > >> but nothing super-easy to use yet. So I think we have to expect that > >> some folks will have lots of regions for a little while yet. > >> > >> Given that people have been testing w/o the TimeoutMonitor, I think we > >> should leave these confs as they are in the current 92 rc and not futz > >> too much. If stuff gets stuck in transition we at least have decent > >> visibility and fix tools compared to what we had in 90. > >> > >> -Todd > >> > >> > On Tue, Jan 3, 2012 at 6:47 PM, Ted Yu <[email protected]> wrote: > >> >> I cloned HBASE-5120 off of HBASE-5119 and marked it as a blocker. > >> >> I think it shows that we may need to revisit HBASE-4015. > >> >> > >> >> Regards > >> >> > >> >> On Tue, Jan 3, 2012 at 5:10 PM, Ted Yu <[email protected]> wrote: > >> >> > >> >>> Shall we also address the scenario where timeout monitor and bulk > >> disabler > >> >>> race against the same region ? > >> >>> See > >> >>> > >> > https://issues.apache.org/jira/browse/HBASE-5119?focusedCommentId=13179176&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13179176 > >> >>> > >> >>> Cheers > >> >>> > >> >>> > >> >>> On Tue, Jan 3, 2012 at 5:04 PM, Stack <[email protected]> wrote: > >> >>> > >> >>>> On Tue, Jan 3, 2012 at 3:12 PM, Jonathan Hsieh <[email protected]> > >> wrote: > >> >>>> > I am similarly concerned about the deadlocks in distributed log > >> >>>> splitting > >> >>>> > that Jimmy and Prakash have been working on. > >> >>>> > > >> >>>> > If distributed long splitting is off by default, I'm +1. If it > is > >> >>>> going to > >> >>>> > be default on, then I'd prefer getting those bugs bumped up to > >> >>>> > blockers fixed and then spinning another rc. > >> >>>> > > >> >>>> > >> >>>> I'll put up a new RC after HBASE-5081 goes in (I'll update our > hadoop > >> >>>> to the released 1.0.0). > >> >>>> > >> >>>> St.Ack > >> >>>> > >> >>> > >> >>> > >> > >> > >> > >> -- > >> Todd Lipcon > >> Software Engineer, Cloudera > >> > > > > -- > Todd Lipcon > Software Engineer, Cloudera >
