Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
MIME-Version: 1.0
In-Reply-To: <CAMUu0w9s0Nt=A9URWrvX_KTUTrOVQ=anf=6xfE98HO5T_zBP8w@mail.gmail.com>
References: <CANZa=Gu-=d_4PGtH6sUfjzM31uQT_Zr1k4-LetEAWq_CfaYk+A@mail.gmail.com>
 <CA+RK=_Asna9NUAhh7OSrrvyafAw30RGNyhTZcmG+7W-u8Q5p+A@mail.gmail.com>
 <CA+RK=_AqQrVpMfRsLrBMorZoWnFBhsfT9oZniE-89276U-6cBw@mail.gmail.com>
 <CAHxLZBV3-EBe8PPhyDXSeVbdSA6D0NvvmX9JemtGLKiSFo45Cg@mail.gmail.com>
 <CA+RK=_BL0f58zYat90t=bb=n_Tf-tZmx6wCs4opRuobAUvGFPw@mail.gmail.com>
 <CADfYSXQOEhy8Q12Ww6egXj7eU7gYhLj96AarLjp_O-Cqk6nhTA@mail.gmail.com>
 <CA+RK=_CQUAXp9PpAPgsvU2J-uwGXWGk7kk8e8p2Q=SyogUkqfA@mail.gmail.com>
 <CA+RK=_BwynTjo4NFBBrmW72q9kbwaa3Egj4m-DLauM9cFC2W8A@mail.gmail.com>
 <CADfYSXSJr1x_XdRhS9JPqNGHQouY4-LxMaFQVFBv5fZx3yq51w@mail.gmail.com>
 <FAE98D47-9DE2-4987-8556-B65FB4FB92DF@gmail.com> <CAMUu0w9s0Nt=A9URWrvX_KTUTrOVQ=anf=6xfE98HO5T_zBP8w@mail.gmail.com>
From: Nick Dimiduk <ndimiduk@apache.org>
Date: Tue, 8 Nov 2016 07:51:54 -0800
Message-ID: <CANZa=GtCGFTaj8oTyM-hMjG+498jw-HzpVGmAn9O1WYq9oa62w@mail.gmail.com>
Subject: Re: [DISCUSS] EOL 1.1 Release Branch
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Cc: hbase-user <user@hbase.apache.org>
Content-Type: multipart/alternative; boundary=047d7bae4242ab97150540cc1e60
archived-at: Tue, 08 Nov 2016 15:52:00 -0000

--047d7bae4242ab97150540cc1e60
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=C3=B6ztutar <enis@apache.org> 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 le=
t
> Andrew do that? I can help as well if needed.
>
> Enis
>
> On Mon, Nov 7, 2016 at 12:17 PM, Andrew Purtell <andrew.purtell@gmail.com
> <javascript:;>>
> wrote:
>
> > I have a patch for this and will be trying it out.
> >
> > On Nov 7, 2016, at 12:00 PM, Gary Helmling <ghelmling@gmail.com
> <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 cal=
l
> > >> 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 win=
d
> up
> > > creating an offline meta entry for rs_p with no regioninfo, similar t=
o
> > > HBASE-16093.  And that entry could wind up hiding the (still online)
> > > daughter regions.
> >
>

--047d7bae4242ab97150540cc1e60--