Going back to the original discussion, the conclusion is to continue with 1.1 line for now, and re-evaluate in a couple of months it seems.
Nick do you want to keep driving the next 1.1 releases, or you want to let Andrew do that? I can help as well if needed. Enis On Mon, Nov 7, 2016 at 12:17 PM, Andrew Purtell <[email protected]> wrote: > I have a patch for this and will be trying it out. > > On Nov 7, 2016, at 12:00 PM, Gary Helmling <[email protected]> wrote: > > >> > >> I'm not deeply familiar with the AssignmentManager. I see when we > process > >> split rollbacks in onRegionSplit() we only call regionOffline() on > >> daughters if they are known to exist. However when processing merge > >> rollbacks in the else case of onRegionMerge() we unconditionally call > >> regionOffline() on the parent-being-merged. Shouldn't that likewise be > >> conditional on regionStates holding a state for the parent-being-merged? > >> Pardon if I've missed something. > >> > >> > > I'm really not familiar with the merge code, but this seems plausible to > > me. I see that onRegionSplit() has an early out at the top of the > method, > > but that will fail to evaluate if rs_a and rs_b are open and rs_p is > null. > > So if it's called with a code of MERGE_REVERTED, I think we could wind up > > creating an offline meta entry for rs_p with no regioninfo, similar to > > HBASE-16093. And that entry could wind up hiding the (still online) > > daughter regions. >
