I'm not convinced this should be a blocker, the TM is effectively disabled in 0.90 and up until Ram brought back the subject it was going to be the same in 0.92.0. HBASE-5120 happens only when you run with the TM.
My opinion is that: - If 5120 is easy to fix and there's no other obvious bug lurking in the TM, we should get 5119/20 into 0.92.0 - If it's not, either punt to a later bug fix release or 0.94 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 J-D 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 >>> >> >>
