You're right Enis, sounds like we'll continue on with 1.1. No issues on my side, I'm happy to continue producing these releases as I'm able.
Thanks everyone for the discussion. On Monday, November 7, 2016, Enis Söztutar <[email protected]> wrote: > 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] > <javascript:;>> > 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] > <javascript:;>> 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. > > >
