I filed HBASE-14503 to disable in branch-1. St.Ack On Wed, Jul 8, 2015 at 7:42 PM, Stack <[email protected]> wrote:
> 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 >> > >> > >
