Thanks Enis. That is a hole. In new runs, I found a new failure mode (See HBASE-14028). I think it will take a week or so to fix both issues -- given it takes a while for tests to complete not to mind I'm slow at the best of times -- and that is presuming I don't find any more new problems. Even then, there are so many moving pieces, I'm not sure how confident I'd be in the end result (If we fail to clear the recovering zk node for any reason, the region goes write-only).
Agree it is a good idea. Assignment hopefully will be very different in 2.0 built on a more solid foundation. Let's redo this good idea atop the new underpinnings. Meantime I'm in favor of disabling it in branch-1 and just removing the current implementation from the code base completely. St.Ack On Wed, Jul 8, 2015 at 6:35 PM, Enis Söztutar <[email protected]> wrote: > On Wed, Jul 8, 2015 at 12:33 PM, Stack <[email protected]> wrote: > > > On Wed, Jul 8, 2015 at 11:48 AM, Enis Söztutar <[email protected]> > wrote: > > > > > ....The other > > > problem is that we cannot have only DLR since if the table is offline > DLS > > > is needed, which forces us to maintain and test two different > subsystems. > > > > > I remembered this from discussions with Jeffrey. Found it in the code in > WALSplitter.java: > > // The following sink is used in distrubitedLogReplay mode for entries > of regions in a disabling > > // table. It's a limitation of distributedLogReplay. Because log replay > needs a region is > > // assigned and online before it can replay wal edits while regions of > disabling/disabled table > > // won't be assigned by AM. We can retire this code after HBASE-8234 > > > > > > Please say more on the above Enis. Trying to understand... > > St.Ack > > >
