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: <CANZa=GtCGFTaj8oTyM-hMjG+498jw-HzpVGmAn9O1WYq9oa62w@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>
 <CANZa=GtCGFTaj8oTyM-hMjG+498jw-HzpVGmAn9O1WYq9oa62w@mail.gmail.com>
From: Andrew Purtell <apurtell@apache.org>
Date: Tue, 8 Nov 2016 08:44:49 -0800
Message-ID: <CA+RK=_D7DsuCdB911i57=nVYKd_MLTWLG3Xk0sAPHhPZ7rN1-g@mail.gmail.com>
Subject: Re: [DISCUSS] EOL 1.1 Release Branch
To: "user@hbase.apache.org" <user@hbase.apache.org>
Cc: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a113ebff847f7d80540ccdedd
archived-at: Tue, 08 Nov 2016 16:45:35 -0000

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

Thanks Nick!

On Tue, Nov 8, 2016 at 7:51 AM, Nick Dimiduk <ndimiduk@apache.org> wrote:

> You're right Enis, sounds like we'll continue on with 1.1. No issues on m=
y
> 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 wi=
th
> > 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 <
> 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 merg=
e
> > > >> rollbacks in the else case of onRegionMerge() we unconditionally
> call
> > > >> regionOffline() on the parent-being-merged. Shouldn't that likewis=
e
> 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 plausib=
le
> > 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 i=
s
> > > 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.
> > >
> >
>


--=20
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

--001a113ebff847f7d80540ccdedd--