[jira] [Resolved] (HBASE-22251) Implement fast fail for async client

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-22251.
---
Resolution: Won't Fix

> Implement fast fail for async client
> 
>
> Key: HBASE-22251
> URL: https://issues.apache.org/jira/browse/HBASE-22251
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Priority: Major
>
> And I think we need to deprecated 
> HConstants.HBASE_CLIENT_FAST_FAIL_INTERCEPTOR_IMPL, it should not be exposes 
> to users as the related classes are all IA.Private.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22307) Deprecated Preemptive Fail Fast

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-22307.
---
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.3.0
   3.0.0

Pushed to master and branch-2.

Thanks [~stack] for reviewing.

> Deprecated Preemptive Fail Fast
> ---
>
> Key: HBASE-22307
> URL: https://issues.apache.org/jira/browse/HBASE-22307
> Project: HBase
>  Issue Type: Task
>  Components: Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
>
> Opened a discuss thread in dev & user mailing list but get no response, so I 
> assume that there is no critical users for this feafure. And the problem we 
> want to solve here is mainly the same with HBASE-16388, so I think user could 
> make use of the config in HBASE-16388.
> Plan to deprecated the related classes and configs on branch-2, and the 
> IA.Private classes will be removed in 3.0.0(on branch HBASE-21512 first), and 
> the constants in HConstants class will be kept till 4.0.0, so we do not break 
> the public API, although it is useless to config them on 3.0.0+.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] Handling removal of deprecated methods and classes

[Misty Linville]

For features, I think we would need to understand the popularity of a given
feature by our user base, and that might vary wildly by feature. Do you
think it would be possible to generalize?

On Wed, Apr 24, 2019 at 9:56 PM Stack  wrote:

> On Wed, Apr 24, 2019 at 9:04 PM Yu Li  wrote:
>
> > ...
> > Thirdly, besides API deprecation, I think we should also discuss about
> the
> > rule for feature deprecation. We ever deprecated DLR, I could observe
> some
> > discussion on deprecating preemptive fast fail recently, and personally I
> > think there're some more features with few usage but making code base
> > complicated.
> >
> >
> I like this suggestion. Lets start a new topic on stuff to remove.
>
> Thanks Yu Li,
> S
>
>
>
>
> > Lastly, I think we need to emphasize on adding the incompatible flag and
> > release note to JIRA and updating document whenever a deprecated
> > feature/API is removed, which IMHO is not followed quite well recently.
> >
> > Thanks.
> >
> > Best Regards,
> > Yu
> >
> >
> > On Thu, 25 Apr 2019 at 10:24, 张铎(Duo Zhang) 
> wrote:
> >
> > > Let's get a conclusion here?
> > >
> > > By default, we should try our best to keep the deprecated APIs for at
> > least
> > > a whole major release. All committers should have this in mind, when
> > there
> > > is patch which deprecates a public API, we should make sure that there
> is
> > > a @deprecated javadoc comment says on which version it is deprecated,
> and
> > > on which version it is expected to be removed.
> > >
> > > And due to the difficulties in real world, if you think the above rule
> > > makes it really hard to maintain a clean and stable code base, you can
> > > break the rule. But you should have a strong enough reason, and also, a
> > > nice written release note, and also update the upgrading section in our
> > ref
> > > guide.
> > >
> > > Is this OK?
> > >
> > > Thanks.
> > >
> > > 张铎(Duo Zhang)  于2019年4月24日周三 下午2:38写道：
> > >
> > > > Phoenix is a good example I'd say, we have done a lot of CP related
> > > > changes before releasing 2.0.0. But until now, Phoenix still has
> > troubles
> > > > to work together with 2.x, although we have already fixed several
> > > > compatibility issues... It shows that, usually people will take much
> > care
> > > > on the alpha and beta releases...
> > > >
> > > > Reid Chan  于2019年4月24日周三 上午10:58写道：
> > > >
> > > >>
> > > >> As a strong coupling system to HBase, Phoenix has always been the
> > first
> > > >> sufferer, not only client APIs, but also some internal APIs.
> > > >> Maybe we can ask Phoenix dev team what do they think, and get some
> > > >> thoughts from them.
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Best regards,
> > > >> R.C
> > > >>
> > > >>
> > > >>
> > > >> 
> > > >> From: Sean Busbey 
> > > >> Sent: 24 April 2019 10:16
> > > >> To: dev
> > > >> Subject: Re: [DISCUSS] Handling removal of deprecated methods and
> > > classes
> > > >>
> > > >> Isn't API stabilization what we have alpha and beta releases for?
> > > >>
> > > >> There was nearly a year between the first alpha version of 2.0.0 and
> > the
> > > >> GA
> > > >> release. Surely that should be a reasonable window for "trying out"
> a
> > > new
> > > >> major release.
> > > >>
> > > >> I don't like the idea of telling our downstreamers that they can't
> > > >> "really"
> > > >> use or rely on our major releases until several minor releases in.
> > > Either
> > > >> we should say "API locks at X.0.0" or we should say "any API change
> > > might
> > > >> happen at a major version".
> > > >>
> > > >> We can always document what went away between minor releases even if
> > we
> > > >> can't give a compile time warning in advance (e.g. for the 2.0.0 to
> > > 3.0.0
> > > >> user in your example Duo).
> > > >>
> > > >> We ended up trying to do that for 2.0.0 because so much had changed
> > from
> > > >> 1.0.0.
> > > >>
> > > >>
> > > >> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang) 
> > > wrote:
> > > >>
> > > >> > Ideally, we'd better keep the deprecated APIs for at least a whole
> > > major
> > > >> > version, that means user can upgrade to a new major release from
> any
> > > >> minor
> > > >> > releases, without seeing the removal of any non-deprecated APIs.
> > > >> >
> > > >> > For example, if we deprecate a method in 2.1.0, and remove it in
> > > 3.0.0,
> > > >> > then the users who upgrade to 3.0.0 from 2.0.0 will see the
> removal
> > of
> > > >> this
> > > >> > method, although the method is not deprecated on 2.0.0.
> > > >> >
> > > >> > But considering the current status of our project(as Sean
> mentioned
> > > >> above),
> > > >> > I do not think it is a good idea to fully follow the rule. One
> more
> > > >> thing
> > > >> > is that, for a new major release, usually the code base is not
> > stable
> > > >> > enough, need to be polished. Ideally it will be stable enough
> after
> > > one
> > > >> or
> > > >> > two minor releases. This means we will in

Re: [DISCUSS] Handling removal of deprecated methods and classes

[Misty Linville]

I’m late on this, but I had this thought. Why not have a minimum
deprecation period of, say, 6 months, after which the API is eligible for
depreciation. At that point, a deprecation can be proposed on a DISCUSS
thread, with plenty of time given for discussion.

On Wed, Apr 24, 2019 at 9:56 PM Stack  wrote:

> On Wed, Apr 24, 2019 at 9:04 PM Yu Li  wrote:
>
> > ...
> > Thirdly, besides API deprecation, I think we should also discuss about
> the
> > rule for feature deprecation. We ever deprecated DLR, I could observe
> some
> > discussion on deprecating preemptive fast fail recently, and personally I
> > think there're some more features with few usage but making code base
> > complicated.
> >
> >
> I like this suggestion. Lets start a new topic on stuff to remove.
>
> Thanks Yu Li,
> S
>
>
>
>
> > Lastly, I think we need to emphasize on adding the incompatible flag and
> > release note to JIRA and updating document whenever a deprecated
> > feature/API is removed, which IMHO is not followed quite well recently.
> >
> > Thanks.
> >
> > Best Regards,
> > Yu
> >
> >
> > On Thu, 25 Apr 2019 at 10:24, 张铎(Duo Zhang) 
> wrote:
> >
> > > Let's get a conclusion here?
> > >
> > > By default, we should try our best to keep the deprecated APIs for at
> > least
> > > a whole major release. All committers should have this in mind, when
> > there
> > > is patch which deprecates a public API, we should make sure that there
> is
> > > a @deprecated javadoc comment says on which version it is deprecated,
> and
> > > on which version it is expected to be removed.
> > >
> > > And due to the difficulties in real world, if you think the above rule
> > > makes it really hard to maintain a clean and stable code base, you can
> > > break the rule. But you should have a strong enough reason, and also, a
> > > nice written release note, and also update the upgrading section in our
> > ref
> > > guide.
> > >
> > > Is this OK?
> > >
> > > Thanks.
> > >
> > > 张铎(Duo Zhang)  于2019年4月24日周三 下午2:38写道：
> > >
> > > > Phoenix is a good example I'd say, we have done a lot of CP related
> > > > changes before releasing 2.0.0. But until now, Phoenix still has
> > troubles
> > > > to work together with 2.x, although we have already fixed several
> > > > compatibility issues... It shows that, usually people will take much
> > care
> > > > on the alpha and beta releases...
> > > >
> > > > Reid Chan  于2019年4月24日周三 上午10:58写道：
> > > >
> > > >>
> > > >> As a strong coupling system to HBase, Phoenix has always been the
> > first
> > > >> sufferer, not only client APIs, but also some internal APIs.
> > > >> Maybe we can ask Phoenix dev team what do they think, and get some
> > > >> thoughts from them.
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Best regards,
> > > >> R.C
> > > >>
> > > >>
> > > >>
> > > >> 
> > > >> From: Sean Busbey 
> > > >> Sent: 24 April 2019 10:16
> > > >> To: dev
> > > >> Subject: Re: [DISCUSS] Handling removal of deprecated methods and
> > > classes
> > > >>
> > > >> Isn't API stabilization what we have alpha and beta releases for?
> > > >>
> > > >> There was nearly a year between the first alpha version of 2.0.0 and
> > the
> > > >> GA
> > > >> release. Surely that should be a reasonable window for "trying out"
> a
> > > new
> > > >> major release.
> > > >>
> > > >> I don't like the idea of telling our downstreamers that they can't
> > > >> "really"
> > > >> use or rely on our major releases until several minor releases in.
> > > Either
> > > >> we should say "API locks at X.0.0" or we should say "any API change
> > > might
> > > >> happen at a major version".
> > > >>
> > > >> We can always document what went away between minor releases even if
> > we
> > > >> can't give a compile time warning in advance (e.g. for the 2.0.0 to
> > > 3.0.0
> > > >> user in your example Duo).
> > > >>
> > > >> We ended up trying to do that for 2.0.0 because so much had changed
> > from
> > > >> 1.0.0.
> > > >>
> > > >>
> > > >> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang) 
> > > wrote:
> > > >>
> > > >> > Ideally, we'd better keep the deprecated APIs for at least a whole
> > > major
> > > >> > version, that means user can upgrade to a new major release from
> any
> > > >> minor
> > > >> > releases, without seeing the removal of any non-deprecated APIs.
> > > >> >
> > > >> > For example, if we deprecate a method in 2.1.0, and remove it in
> > > 3.0.0,
> > > >> > then the users who upgrade to 3.0.0 from 2.0.0 will see the
> removal
> > of
> > > >> this
> > > >> > method, although the method is not deprecated on 2.0.0.
> > > >> >
> > > >> > But considering the current status of our project(as Sean
> mentioned
> > > >> above),
> > > >> > I do not think it is a good idea to fully follow the rule. One
> more
> > > >> thing
> > > >> > is that, for a new major release, usually the code base is not
> > stable
> > > >> > enough, need to be polished. Ideally it will be stable enough
> after
> >

Re: [DISCUSS] Handling removal of deprecated methods and classes

[Stack]

On Wed, Apr 24, 2019 at 9:04 PM Yu Li  wrote:

> ...
> Thirdly, besides API deprecation, I think we should also discuss about the
> rule for feature deprecation. We ever deprecated DLR, I could observe some
> discussion on deprecating preemptive fast fail recently, and personally I
> think there're some more features with few usage but making code base
> complicated.
>
>
I like this suggestion. Lets start a new topic on stuff to remove.

Thanks Yu Li,
S




> Lastly, I think we need to emphasize on adding the incompatible flag and
> release note to JIRA and updating document whenever a deprecated
> feature/API is removed, which IMHO is not followed quite well recently.
>
> Thanks.
>
> Best Regards,
> Yu
>
>
> On Thu, 25 Apr 2019 at 10:24, 张铎(Duo Zhang)  wrote:
>
> > Let's get a conclusion here?
> >
> > By default, we should try our best to keep the deprecated APIs for at
> least
> > a whole major release. All committers should have this in mind, when
> there
> > is patch which deprecates a public API, we should make sure that there is
> > a @deprecated javadoc comment says on which version it is deprecated, and
> > on which version it is expected to be removed.
> >
> > And due to the difficulties in real world, if you think the above rule
> > makes it really hard to maintain a clean and stable code base, you can
> > break the rule. But you should have a strong enough reason, and also, a
> > nice written release note, and also update the upgrading section in our
> ref
> > guide.
> >
> > Is this OK?
> >
> > Thanks.
> >
> > 张铎(Duo Zhang)  于2019年4月24日周三 下午2:38写道：
> >
> > > Phoenix is a good example I'd say, we have done a lot of CP related
> > > changes before releasing 2.0.0. But until now, Phoenix still has
> troubles
> > > to work together with 2.x, although we have already fixed several
> > > compatibility issues... It shows that, usually people will take much
> care
> > > on the alpha and beta releases...
> > >
> > > Reid Chan  于2019年4月24日周三 上午10:58写道：
> > >
> > >>
> > >> As a strong coupling system to HBase, Phoenix has always been the
> first
> > >> sufferer, not only client APIs, but also some internal APIs.
> > >> Maybe we can ask Phoenix dev team what do they think, and get some
> > >> thoughts from them.
> > >>
> > >>
> > >> --
> > >>
> > >> Best regards,
> > >> R.C
> > >>
> > >>
> > >>
> > >> 
> > >> From: Sean Busbey 
> > >> Sent: 24 April 2019 10:16
> > >> To: dev
> > >> Subject: Re: [DISCUSS] Handling removal of deprecated methods and
> > classes
> > >>
> > >> Isn't API stabilization what we have alpha and beta releases for?
> > >>
> > >> There was nearly a year between the first alpha version of 2.0.0 and
> the
> > >> GA
> > >> release. Surely that should be a reasonable window for "trying out" a
> > new
> > >> major release.
> > >>
> > >> I don't like the idea of telling our downstreamers that they can't
> > >> "really"
> > >> use or rely on our major releases until several minor releases in.
> > Either
> > >> we should say "API locks at X.0.0" or we should say "any API change
> > might
> > >> happen at a major version".
> > >>
> > >> We can always document what went away between minor releases even if
> we
> > >> can't give a compile time warning in advance (e.g. for the 2.0.0 to
> > 3.0.0
> > >> user in your example Duo).
> > >>
> > >> We ended up trying to do that for 2.0.0 because so much had changed
> from
> > >> 1.0.0.
> > >>
> > >>
> > >> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang) 
> > wrote:
> > >>
> > >> > Ideally, we'd better keep the deprecated APIs for at least a whole
> > major
> > >> > version, that means user can upgrade to a new major release from any
> > >> minor
> > >> > releases, without seeing the removal of any non-deprecated APIs.
> > >> >
> > >> > For example, if we deprecate a method in 2.1.0, and remove it in
> > 3.0.0,
> > >> > then the users who upgrade to 3.0.0 from 2.0.0 will see the removal
> of
> > >> this
> > >> > method, although the method is not deprecated on 2.0.0.
> > >> >
> > >> > But considering the current status of our project(as Sean mentioned
> > >> above),
> > >> > I do not think it is a good idea to fully follow the rule. One more
> > >> thing
> > >> > is that, for a new major release, usually the code base is not
> stable
> > >> > enough, need to be polished. Ideally it will be stable enough after
> > one
> > >> or
> > >> > two minor releases. This means we will introduced new APIs and
> > >> deprecated
> > >> > old APIs in these minor releases. I think this is because that we do
> > not
> > >> > have enough test before making a new major release, but this is a
> dead
> > >> lock
> > >> > problem. If we do not publish a new major release, users will not
> try
> > it
> > >> > which means we can not get enough test, since HBase is widely used
> > >> > everywhere and the release manager can only test a small set of core
> > >> > features...
> > >> >
> > >> > For me, I think a better way is

Re: [DISCUSS] Handling removal of deprecated methods and classes

[Stack]

On Wed, Apr 24, 2019 at 7:24 PM 张铎(Duo Zhang)  wrote:

> Let's get a conclusion here?
>
> By default, we should try our best to keep the deprecated APIs for at least
> a whole major release.


I agree with this. Trying to message anything else would be too hard for
devs and users to keep straight (To my mind, the fact that major releases
take so long is a separate issue).


And due to the difficulties in real world, if you think the above rule
> makes it really hard to maintain a clean and stable code base, you can
> break the rule. But you should have a strong enough reason, and also, a
> nice written release note, and also update the upgrading section in our ref
> guide.
>
> Is this OK?
>
>
This is good by me (as long as the 'break the rule' is super rare).

S



> Thanks.
>
> 张铎(Duo Zhang)  于2019年4月24日周三 下午2:38写道：
>
> > Phoenix is a good example I'd say, we have done a lot of CP related
> > changes before releasing 2.0.0. But until now, Phoenix still has troubles
> > to work together with 2.x, although we have already fixed several
> > compatibility issues... It shows that, usually people will take much care
> > on the alpha and beta releases...
> >
> > Reid Chan  于2019年4月24日周三 上午10:58写道：
> >
> >>
> >> As a strong coupling system to HBase, Phoenix has always been the first
> >> sufferer, not only client APIs, but also some internal APIs.
> >> Maybe we can ask Phoenix dev team what do they think, and get some
> >> thoughts from them.
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> R.C
> >>
> >>
> >>
> >> 
> >> From: Sean Busbey 
> >> Sent: 24 April 2019 10:16
> >> To: dev
> >> Subject: Re: [DISCUSS] Handling removal of deprecated methods and
> classes
> >>
> >> Isn't API stabilization what we have alpha and beta releases for?
> >>
> >> There was nearly a year between the first alpha version of 2.0.0 and the
> >> GA
> >> release. Surely that should be a reasonable window for "trying out" a
> new
> >> major release.
> >>
> >> I don't like the idea of telling our downstreamers that they can't
> >> "really"
> >> use or rely on our major releases until several minor releases in.
> Either
> >> we should say "API locks at X.0.0" or we should say "any API change
> might
> >> happen at a major version".
> >>
> >> We can always document what went away between minor releases even if we
> >> can't give a compile time warning in advance (e.g. for the 2.0.0 to
> 3.0.0
> >> user in your example Duo).
> >>
> >> We ended up trying to do that for 2.0.0 because so much had changed from
> >> 1.0.0.
> >>
> >>
> >> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang) 
> wrote:
> >>
> >> > Ideally, we'd better keep the deprecated APIs for at least a whole
> major
> >> > version, that means user can upgrade to a new major release from any
> >> minor
> >> > releases, without seeing the removal of any non-deprecated APIs.
> >> >
> >> > For example, if we deprecate a method in 2.1.0, and remove it in
> 3.0.0,
> >> > then the users who upgrade to 3.0.0 from 2.0.0 will see the removal of
> >> this
> >> > method, although the method is not deprecated on 2.0.0.
> >> >
> >> > But considering the current status of our project(as Sean mentioned
> >> above),
> >> > I do not think it is a good idea to fully follow the rule. One more
> >> thing
> >> > is that, for a new major release, usually the code base is not stable
> >> > enough, need to be polished. Ideally it will be stable enough after
> one
> >> or
> >> > two minor releases. This means we will introduced new APIs and
> >> deprecated
> >> > old APIs in these minor releases. I think this is because that we do
> not
> >> > have enough test before making a new major release, but this is a dead
> >> lock
> >> > problem. If we do not publish a new major release, users will not try
> it
> >> > which means we can not get enough test, since HBase is widely used
> >> > everywhere and the release manager can only test a small set of core
> >> > features...
> >> >
> >> > For me, I think a better way is to not follow the rule for the first
> >> > several releases, i.e, we are free to remove APIs in the next major
> >> release
> >> > if they are deprecated in x.1.0 and x.2.0 releases. But once we think
> >> the
> >> > APIs are stable enough, we should follow the rule again, i.e, newly
> >> > deprecated APIs should be retained in the next major release. For
> >> example,
> >> > for 2.x release, I think the stable minor release would be 2.3.0 or
> >> 2.4.0,
> >> > which means if the APIs you used are not deprecated in these minor
> >> release,
> >> > then you can confirm that you can still use it in the next major
> >> release.
> >> > But for minor releases before it, for example, 2.1.x and 2.0.x, you'd
> >> > better upgrade to 2.3.0 or 2.4.0 first, as the APIs you used may
> >> disappear
> >> > even if they are not deprecated.
> >> >
> >> > And we can add the above words in the upgrading part in our ref guide.
> >> >
> >> > Thanks.
> >> >
> >> >

Re: [DISCUSS] Handling removal of deprecated methods and classes

[Yu Li]

TL;DR: I agree with Duo's proposal, that we keep the base rule in mind but
allow exceptional case with adequate discussion and fine documentation.

First of all, I'd like to express my personal appreciation for the efforts
spent on removing deprecated codes and bringing up the discussion.

Secondly, I agree with Sean that the base rule has no problem, but the real
problem is we're observing a (pretty much) slowing down on major release
period, which causes deprecated codes live for much longer than it's ought
to. Maybe it's a little bit off the track but should we start another
thread discussing about our roadmap for 3.0 or even further?

Thirdly, besides API deprecation, I think we should also discuss about the
rule for feature deprecation. We ever deprecated DLR, I could observe some
discussion on deprecating preemptive fast fail recently, and personally I
think there're some more features with few usage but making code base
complicated.

Lastly, I think we need to emphasize on adding the incompatible flag and
release note to JIRA and updating document whenever a deprecated
feature/API is removed, which IMHO is not followed quite well recently.

Thanks.

Best Regards,
Yu


On Thu, 25 Apr 2019 at 10:24, 张铎(Duo Zhang)  wrote:

> Let's get a conclusion here?
>
> By default, we should try our best to keep the deprecated APIs for at least
> a whole major release. All committers should have this in mind, when there
> is patch which deprecates a public API, we should make sure that there is
> a @deprecated javadoc comment says on which version it is deprecated, and
> on which version it is expected to be removed.
>
> And due to the difficulties in real world, if you think the above rule
> makes it really hard to maintain a clean and stable code base, you can
> break the rule. But you should have a strong enough reason, and also, a
> nice written release note, and also update the upgrading section in our ref
> guide.
>
> Is this OK?
>
> Thanks.
>
> 张铎(Duo Zhang)  于2019年4月24日周三 下午2:38写道：
>
> > Phoenix is a good example I'd say, we have done a lot of CP related
> > changes before releasing 2.0.0. But until now, Phoenix still has troubles
> > to work together with 2.x, although we have already fixed several
> > compatibility issues... It shows that, usually people will take much care
> > on the alpha and beta releases...
> >
> > Reid Chan  于2019年4月24日周三 上午10:58写道：
> >
> >>
> >> As a strong coupling system to HBase, Phoenix has always been the first
> >> sufferer, not only client APIs, but also some internal APIs.
> >> Maybe we can ask Phoenix dev team what do they think, and get some
> >> thoughts from them.
> >>
> >>
> >> --
> >>
> >> Best regards,
> >> R.C
> >>
> >>
> >>
> >> 
> >> From: Sean Busbey 
> >> Sent: 24 April 2019 10:16
> >> To: dev
> >> Subject: Re: [DISCUSS] Handling removal of deprecated methods and
> classes
> >>
> >> Isn't API stabilization what we have alpha and beta releases for?
> >>
> >> There was nearly a year between the first alpha version of 2.0.0 and the
> >> GA
> >> release. Surely that should be a reasonable window for "trying out" a
> new
> >> major release.
> >>
> >> I don't like the idea of telling our downstreamers that they can't
> >> "really"
> >> use or rely on our major releases until several minor releases in.
> Either
> >> we should say "API locks at X.0.0" or we should say "any API change
> might
> >> happen at a major version".
> >>
> >> We can always document what went away between minor releases even if we
> >> can't give a compile time warning in advance (e.g. for the 2.0.0 to
> 3.0.0
> >> user in your example Duo).
> >>
> >> We ended up trying to do that for 2.0.0 because so much had changed from
> >> 1.0.0.
> >>
> >>
> >> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang) 
> wrote:
> >>
> >> > Ideally, we'd better keep the deprecated APIs for at least a whole
> major
> >> > version, that means user can upgrade to a new major release from any
> >> minor
> >> > releases, without seeing the removal of any non-deprecated APIs.
> >> >
> >> > For example, if we deprecate a method in 2.1.0, and remove it in
> 3.0.0,
> >> > then the users who upgrade to 3.0.0 from 2.0.0 will see the removal of
> >> this
> >> > method, although the method is not deprecated on 2.0.0.
> >> >
> >> > But considering the current status of our project(as Sean mentioned
> >> above),
> >> > I do not think it is a good idea to fully follow the rule. One more
> >> thing
> >> > is that, for a new major release, usually the code base is not stable
> >> > enough, need to be polished. Ideally it will be stable enough after
> one
> >> or
> >> > two minor releases. This means we will introduced new APIs and
> >> deprecated
> >> > old APIs in these minor releases. I think this is because that we do
> not
> >> > have enough test before making a new major release, but this is a dead
> >> lock
> >> > problem. If we do not publish a new major release, users will

[jira] [Created] (HBASE-22307) Deprecated Preemptive Fail Fast and remove the support in 3.0.0

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-22307:
-

 Summary: Deprecated Preemptive Fail Fast and remove the support in 
3.0.0
 Key: HBASE-22307
 URL: https://issues.apache.org/jira/browse/HBASE-22307
 Project: HBase
  Issue Type: Task
  Components: Client
Reporter: Duo Zhang
Assignee: Duo Zhang


Opened a discuss thread in dev & user mailing list but get no response, so I 
assume that there is no critical users for this feafure. And the problem we 
want to solve here is mainly the same with HBASE-16388, so I think user could 
make use of the config in HBASE-16388.

Plan to deprecated the related classes and configs on branch-2, and the 
IA.Private classes will be removed in 3.0.0, and the constants in HConstants 
class will be kept till 4.0.0, so we do not break the public API, although it 
is useless to config them on 3.0.0+.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] Handling removal of deprecated methods and classes

[Duo Zhang]

Let's get a conclusion here?

By default, we should try our best to keep the deprecated APIs for at least
a whole major release. All committers should have this in mind, when there
is patch which deprecates a public API, we should make sure that there is
a @deprecated javadoc comment says on which version it is deprecated, and
on which version it is expected to be removed.

And due to the difficulties in real world, if you think the above rule
makes it really hard to maintain a clean and stable code base, you can
break the rule. But you should have a strong enough reason, and also, a
nice written release note, and also update the upgrading section in our ref
guide.

Is this OK?

Thanks.

张铎(Duo Zhang)  于2019年4月24日周三 下午2:38写道：

> Phoenix is a good example I'd say, we have done a lot of CP related
> changes before releasing 2.0.0. But until now, Phoenix still has troubles
> to work together with 2.x, although we have already fixed several
> compatibility issues... It shows that, usually people will take much care
> on the alpha and beta releases...
>
> Reid Chan  于2019年4月24日周三 上午10:58写道：
>
>>
>> As a strong coupling system to HBase, Phoenix has always been the first
>> sufferer, not only client APIs, but also some internal APIs.
>> Maybe we can ask Phoenix dev team what do they think, and get some
>> thoughts from them.
>>
>>
>> --
>>
>> Best regards,
>> R.C
>>
>>
>>
>> 
>> From: Sean Busbey 
>> Sent: 24 April 2019 10:16
>> To: dev
>> Subject: Re: [DISCUSS] Handling removal of deprecated methods and classes
>>
>> Isn't API stabilization what we have alpha and beta releases for?
>>
>> There was nearly a year between the first alpha version of 2.0.0 and the
>> GA
>> release. Surely that should be a reasonable window for "trying out" a new
>> major release.
>>
>> I don't like the idea of telling our downstreamers that they can't
>> "really"
>> use or rely on our major releases until several minor releases in. Either
>> we should say "API locks at X.0.0" or we should say "any API change might
>> happen at a major version".
>>
>> We can always document what went away between minor releases even if we
>> can't give a compile time warning in advance (e.g. for the 2.0.0 to 3.0.0
>> user in your example Duo).
>>
>> We ended up trying to do that for 2.0.0 because so much had changed from
>> 1.0.0.
>>
>>
>> On Tue, Apr 23, 2019, 20:51 张铎(Duo Zhang)  wrote:
>>
>> > Ideally, we'd better keep the deprecated APIs for at least a whole major
>> > version, that means user can upgrade to a new major release from any
>> minor
>> > releases, without seeing the removal of any non-deprecated APIs.
>> >
>> > For example, if we deprecate a method in 2.1.0, and remove it in 3.0.0,
>> > then the users who upgrade to 3.0.0 from 2.0.0 will see the removal of
>> this
>> > method, although the method is not deprecated on 2.0.0.
>> >
>> > But considering the current status of our project(as Sean mentioned
>> above),
>> > I do not think it is a good idea to fully follow the rule. One more
>> thing
>> > is that, for a new major release, usually the code base is not stable
>> > enough, need to be polished. Ideally it will be stable enough after one
>> or
>> > two minor releases. This means we will introduced new APIs and
>> deprecated
>> > old APIs in these minor releases. I think this is because that we do not
>> > have enough test before making a new major release, but this is a dead
>> lock
>> > problem. If we do not publish a new major release, users will not try it
>> > which means we can not get enough test, since HBase is widely used
>> > everywhere and the release manager can only test a small set of core
>> > features...
>> >
>> > For me, I think a better way is to not follow the rule for the first
>> > several releases, i.e, we are free to remove APIs in the next major
>> release
>> > if they are deprecated in x.1.0 and x.2.0 releases. But once we think
>> the
>> > APIs are stable enough, we should follow the rule again, i.e, newly
>> > deprecated APIs should be retained in the next major release. For
>> example,
>> > for 2.x release, I think the stable minor release would be 2.3.0 or
>> 2.4.0,
>> > which means if the APIs you used are not deprecated in these minor
>> release,
>> > then you can confirm that you can still use it in the next major
>> release.
>> > But for minor releases before it, for example, 2.1.x and 2.0.x, you'd
>> > better upgrade to 2.3.0 or 2.4.0 first, as the APIs you used may
>> disappear
>> > even if they are not deprecated.
>> >
>> > And we can add the above words in the upgrading part in our ref guide.
>> >
>> > Thanks.
>> >
>> > Zach York  于2019年4月24日周三 上午3:04写道：
>> >
>> > > Always good to see the history of the discussion :) It looks like
>> nothing
>> > > really was decided last time (use caution if removing before a full
>> major
>> > > version), hopefully we can come up with something more descriptive
>> this
>> > > time.
>> > >
>> > > I 

[jira] [Resolved] (HBASE-22215) Backport MultiRowRangeFilter does not work with reverse scans

[Xu Cang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xu Cang resolved HBASE-22215.
-
Resolution: Fixed

> Backport MultiRowRangeFilter does not work with reverse scans
> -
>
> Key: HBASE-22215
> URL: https://issues.apache.org/jira/browse/HBASE-22215
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 1.5.0, 1.4.10
>
> Attachments: HBASE-22215.001.branch-1.patch, HBASE-22215.001.patch
>
>
> See parent. Modify and apply to 1.x lines.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (HBASE-22215) Backport MultiRowRangeFilter does not work with reverse scans

[Xu Cang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xu Cang reopened HBASE-22215:
-

> Backport MultiRowRangeFilter does not work with reverse scans
> -
>
> Key: HBASE-22215
> URL: https://issues.apache.org/jira/browse/HBASE-22215
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filters
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Fix For: 1.5.0, 1.4.10
>
> Attachments: HBASE-22215.001.branch-1.patch, HBASE-22215.001.patch
>
>
> See parent. Modify and apply to 1.x lines.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22306) Improve SLB to distribute table regions across all region servers

[Biju Nair (JIRA)]

Biju Nair created HBASE-22306:
-

 Summary: Improve SLB to distribute table regions across all region 
servers
 Key: HBASE-22306
 URL: https://issues.apache.org/jira/browse/HBASE-22306
 Project: HBase
  Issue Type: Improvement
  Components: Balancer
Reporter: Biju Nair


Noticed in clusters that distribution of regions of tables are skewed. From 
quick tests, it looks like that the current table skew cost may not be having 
any influence on selecting the target "cluster" candidate.


{noformat}
Cluster: 
Nodes  regions  Tables 
  5      50       5 

Test 1: Initial Distribution
———
Table 0 regions [1, 1, 2, 4, 2]
Table 1 regions [1, 2, 4, 2, 2]
Table 2 regions [0, 2, 2, 0, 4]
Table 3 regions [0, 5, 0, 2, 3]
Table 4 regions [0, 2, 4, 4, 1]

Test 1: After Balancer Run
———
Table 0 regions [2, 2, 2, 2, 2]
Table 1 regions [2, 2, 3, 2, 2]
Table 2 regions [1, 2, 2, 2, 1]
Table 3 regions [2, 3, 0, 2, 3]
Table 4 regions [3, 1, 3, 2, 2]

Test 2: Initial Distribution
———
Table 0 regions [2, 1, 0, 1, 2]
Table 1 regions [5, 1, 1, 2, 1]
Table 2 regions [2, 4, 0, 2, 4]
Table 3 regions [1, 4, 1, 3, 1]
Table 4 regions [2, 2, 0, 4, 4]

Test 2: After Balancer Run
———-
Table 0 regions [1, 2, 2, 1, 0]
Table 1 regions [2, 2, 2, 2, 2]
Table 2 regions [3, 3, 1, 2, 3]
Table 3 regions [2, 2, 2, 2, 2]
Table 4 regions [2, 1, 3, 3, 3]{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22270) master's jmx.clusterRequests could be negative in branch-1

[Andrew Purtell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Purtell resolved HBASE-22270.

   Resolution: Fixed
 Assignee: puleya7
 Hadoop Flags: Reviewed
Fix Version/s: 1.3.5
   1.4.10
   1.5.0

> master's jmx.clusterRequests could be negative in branch-1
> --
>
> Key: HBASE-22270
> URL: https://issues.apache.org/jira/browse/HBASE-22270
> Project: HBase
>  Issue Type: Bug
>  Components: master, regionserver
>Affects Versions: 1.4.9, 1.3.4, 1.2.12
>Reporter: puleya7
>Assignee: puleya7
>Priority: Major
> Fix For: 1.5.0, 1.4.10, 1.3.5
>
>
> In 1.x branch, regionserver could report a negative  (overflow) requestCount 
> to master, causing the master's jmx.clusterRequests to become smaller even 
> negative
> HBASE-12444 fixed, but missed a little when backport to branch-1



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] switch from "Ammending-Author" to "Co-authored-by" in commit messages

[Andrew Purtell]

I think it was me who introduced the 'Amending-Author' thing.

I started tagging commits this way when I made substantial changes to get a
cherry pick to apply, when I did anything more substantial than trivial
changes like massaging imports.

The tag implies I may be responsible for breakage, not the original author.

Co-authored-by seems fine to do instead. It's not quite equivalent but the
effect should be the same, all of the "co-authors" will be pinged if
they've possibly broken something, not just the original/primary author.


On Tue, Apr 23, 2019 at 7:01 PM OpenInx  wrote:

> +1, thanks Sean.
>
> On Wed, Apr 24, 2019 at 2:15 AM Josh Elser  wrote:
>
> > sgtm.
> >
> > On 4/23/19 10:55 AM, Sean Busbey wrote:
> > > Hi Folks!
> > >
> > > We have an established practice of using a git commit message trailer
> > > of "Amending-Author" when there's multiple authors for a commit[1].
> > >
> > > For example:
> > >
> > > 
> > > commit 946bc19242a460352e70a167eff5361ab3eb4967
> > > Author: Sergey Shelukhin 
> > > Date:   Sat Feb 2 11:00:53 2019 +0800
> > >
> > >  HBASE-21811 region can be opened on two servers due to race
> > > condition with procedures and server reports
> > >
> > >  The original fix is provided by Sergey Shelukhin, the UT is added
> > > by Duo Zhang
> > >
> > >  Amending-Author: Duo Zhang 
> > >  Signed-off-by: Duo Zhang 
> > > 
> > >
> > > A bit over a year ago GitHub rolled out a feature called "co authors"
> > > that they use across the github UI to handle attributing multiple
> > > authors[2]. This feature relies on the git commit message trailer of
> > > "Co-authored-by". Besides the different tag name, it essentially can
> > > be used exactly as we've been using "Amending-Author".
> > >
> > > With our increasing visibility on GitHub, I think we should
> > > discontinue use of "Amending-Author" and just make use of
> > > "Co-authored-by" so that contributors can see their work show up via
> > > the various GitHub niceties.
> > >
> > > If everyone is fine with this I'll update the ref guide.
> > >
> > > -busbey
> > >
> > > [1]:
> > >
> > > Our use of Amending-Author started as a way of attributing differences
> > > between the version of a patch that landed in master and cherry-picked
> > > backports needed for other branches. The generalization to "additional
> > > contributors" just kind of happened.
> > >
> > > http://hbase.apache.org/book.html#committer.amending.author
> > > https://s.apache.org/vsob
> > >
> > > [2]:
> > >
> > > GitHub's announcement and docs on the multiple author feature:
> > >
> > > https://github.blog/2018-01-29-commit-together-with-co-authors/
> > >
> >
> https://help.github.com/en/articles/creating-a-commit-with-multiple-authors
> > >
> > > An arbitrary number of Co-authored-by trailers can be present; one per
> > > line. To be clear, the person who shows up in the Author field on the
> > > commit message does not need to be listed in the Co-authored-by
> > > section.
> > >
> >
>


-- 
Best regards,
Andrew

Words like orphans lost among the crosstalk, meaning torn from truth's
decrepit hands
   - A23, Crosstalk

Re: [VOTE] HBase Connectors 1.0.0RC0

[Sean Busbey]

-1

Bad:
* source artifact is missing NOTICE file
* binary artifacts is missing both LICENSE and NOTICE file
* maven repo artifact 'hbase-connectors-assembly' tgz is missing
LICENSE and NOTICE file

Good:
* signatures good
* checksums good
* maven staged repo looks reasonable

Nit:
* Why are we excluding README.md from rat instead of just giving them
headers? It should be the same as the headers we have in the generated
RELEASENOTES.md and CHANGELOG.md
* Worth a pass making sure relevant stuff has the correct fix version
and jira release notes so it ends up in RELEASENOTES and not just
CHANGELOG. In particular, this first release has two major things: the
kafka proxy (HBASE-15320) and the spark connector (HBASE-13992,
HBASE-14789). Neither of those are in RELEASENOTES, the spark ones
aren't included at all.


On Tue, Apr 23, 2019 at 7:27 AM Balazs Meszaros
 wrote:
>
> Please vote on this Apache HBase Connectors release candidate.
>
> The release files including signatures can be found at:
> http://home.apache.org/~meszibalu/hbase-connectors-1.0.0RC0/
> and maven artifacts are available here:
> https://repository.apache.org/content/repositories/orgapachehbase-1305/
>
> Artifacts were signed with meszib...@apache.org key which can be found at:
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> Compatibility information:
> - scala 2.11
> - spark 2.4
> - kafka 2.0
>
> It's going to be the first release of hbase-connectors. I have updated the
> documentation for kafka connector [1]. Please follow those steps when
> testing.  Spark documentation is pretty good in the refguide [2].
>
> Please note that HBASE-20884 [3] is required for spark, so HBase-2.0.4 or
> HBase-2.1.1 is required at least.
>
> Please try out the candidate and vote +1/0/-1.
>
> Let me be the first who votes.
>
> +1 (not surprisingly)
>
> - signatures, checksums: OK
> - apache rat check: OK
> - built from source (8u112): OK
> - unit tests: OK
> - kafka connector between hbase-2.1.4 and kafka-2.0.0 : OK
> - spark sql select / insert between hbase-2.1.4 and spark-2.4.0: OK
>
> Best regards,
> Balazs
>
> [1] https://github.com/apache/hbase-connectors/tree/master/kafka
> [2] http://hbase.apache.org/book.html#spark
> [3] https://issues.apache.org/jira/browse/HBASE-20884

Re: [VOTE] The first HBase 1.3.4 release candidate (RC0) is available

[Sean Busbey]

+1

Good:
* checksums, signatures
* LICENSE/NOTICE
* staged maven repo looks fine


On Mon, Apr 15, 2019 at 4:10 AM Francis Liu  wrote:
>
> Hi Folks,
>
> The first HBase 1.3.4 release candidate (RC0) is available for download at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/ and Maven
> artifacts are available in the temporary repository
> *https://repository.apache.org/content/repositories/orgapachehbase-1302/
> *
>
> The git tag corresponding to the candidate is '1.3.4RC0' (5d44375).
>
> A detailed source and binary compatibility report for this release is
> available at
> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/compat-check-report.html
> .
> Please review and raise any concerns if you have them.
>
> A list of the 25 issues resolved in this release can be found at
>  https://s.apache.org/uyEI .
>
> Please try out the candidate and vote +1/0/-1.
>
> Prior to making this announcement I made the following checks:
>
> RAT check passes (7u211)
> Unit test suite passes (7u211)
> Loaded the UI in a browser, poked around (8u144)
> A few shell commands (8u144)
> ITBLL 25M rows (8u144)
>
> This vote will be open for one week and close April 22, 2018.
>
> Thanks,
> Francis

[jira] [Resolved] (HBASE-22294) Remove deprecated method from WALKeyImpl

[Jan Hentschel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Hentschel resolved HBASE-22294.
---
  Resolution: Fixed
Hadoop Flags: Incompatible change
Release Note: Removed WALKeyImpl#getLogSeqNum, which was deprecated in 
2.0.0 by HBASE-15158. Use WALKeyImpl#getSequenceId instead.

> Remove deprecated method from WALKeyImpl
> 
>
> Key: HBASE-22294
> URL: https://issues.apache.org/jira/browse/HBASE-22294
> Project: HBase
>  Issue Type: Task
>Reporter: Sayed Anisul Hoque
>Assignee: Sayed Anisul Hoque
>Priority: Minor
> Fix For: 3.0.0
>
>
> the method - _getLogSeqNum_ in the class WALKeyImpl is a deprecated function 
> that needs to be removed in 3.0.0
> According to [HBASE-15158|https://issues.apache.org/jira/browse/HBASE-15158] 
> this function is deprecated in 2.0.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22304) Fix remaining Checkstyle issues in hbase-endpoint

[Jan Hentschel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Hentschel resolved HBASE-22304.
---
   Resolution: Fixed
Fix Version/s: 2.2.1
   2.1.5
   2.3.0
   3.0.0

> Fix remaining Checkstyle issues in hbase-endpoint
> -
>
> Key: HBASE-22304
> URL: https://issues.apache.org/jira/browse/HBASE-22304
> Project: HBase
>  Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Fix For: 3.0.0, 2.3.0, 2.1.5, 2.2.1
>
>
> The module {{hbase-endpoint}} still has a small number of Checkstyle issues, 
> which should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] The first HBase 1.3.4 release candidate (RC0) is available

[Josh Elser]

+1 (binding)

Sorry for the delayed vote, Francis.

* xsums/sigs are OK
* src release looks OK (apache-rat-check and what not)
* Can build from src
* Can run some tests from the src

On 4/15/19 5:09 AM, Francis Liu wrote:

Hi Folks,

The first HBase 1.3.4 release candidate (RC0) is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/ and Maven
artifacts are available in the temporary repository
*https://repository.apache.org/content/repositories/orgapachehbase-1302/
*

The git tag corresponding to the candidate is '1.3.4RC0' (5d44375).

A detailed source and binary compatibility report for this release is
available at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/compat-check-report.html
.
Please review and raise any concerns if you have them.

A list of the 25 issues resolved in this release can be found at
  https://s.apache.org/uyEI .

Please try out the candidate and vote +1/0/-1.

Prior to making this announcement I made the following checks:

 RAT check passes (7u211)
 Unit test suite passes (7u211)
 Loaded the UI in a browser, poked around (8u144)
 A few shell commands (8u144)
 ITBLL 25M rows (8u144)

This vote will be open for one week and close April 22, 2018.

Thanks,
Francis

Re: [VOTE] HBase Connectors 1.0.0RC0

[Stack]

+1

Checked signature, hash, and layout. Built from src. Ran all unit tests.

Thanks for pushing on this Balazs.

S


[INFO]

[INFO] Reactor Summary for Apache HBase Connectors 1.0.0:
[INFO]
[INFO] Apache HBase Connectors  SUCCESS [
1.759 s]
[INFO] Apache HBase - Kafka ... SUCCESS [
0.046 s]
[INFO] Apache HBase - Model Objects for Kafka Proxy ... SUCCESS [
1.977 s]
[INFO] Apache HBase - Kafka Proxy . SUCCESS [
8.597 s]
[INFO] Apache HBase - Spark ... SUCCESS [
0.039 s]
[INFO] Apache HBase - Spark Connector . SUCCESS [03:52
min]
[INFO] Apache HBase - Spark Integration Tests . SUCCESS [06:47
min]
[INFO] Apache HBase Connectors - Assembly . SUCCESS [
7.874 s]
[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time:  11:00 min
[INFO] Finished at: 2019-04-24T11:32:32-07:00
[INFO]




On Tue, Apr 23, 2019 at 5:27 AM Balazs Meszaros
 wrote:

> Please vote on this Apache HBase Connectors release candidate.
>
> The release files including signatures can be found at:
> http://home.apache.org/~meszibalu/hbase-connectors-1.0.0RC0/
> and maven artifacts are available here:
> https://repository.apache.org/content/repositories/orgapachehbase-1305/
>
> Artifacts were signed with meszib...@apache.org key which can be found at:
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> Compatibility information:
> - scala 2.11
> - spark 2.4
> - kafka 2.0
>
> It's going to be the first release of hbase-connectors. I have updated the
> documentation for kafka connector [1]. Please follow those steps when
> testing.  Spark documentation is pretty good in the refguide [2].
>
> Please note that HBASE-20884 [3] is required for spark, so HBase-2.0.4 or
> HBase-2.1.1 is required at least.
>
> Please try out the candidate and vote +1/0/-1.
>
> Let me be the first who votes.
>
> +1 (not surprisingly)
>
> - signatures, checksums: OK
> - apache rat check: OK
> - built from source (8u112): OK
> - unit tests: OK
> - kafka connector between hbase-2.1.4 and kafka-2.0.0 : OK
> - spark sql select / insert between hbase-2.1.4 and spark-2.4.0: OK
>
> Best regards,
> Balazs
>
> [1] https://github.com/apache/hbase-connectors/tree/master/kafka
> [2] http://hbase.apache.org/book.html#spark
> [3] https://issues.apache.org/jira/browse/HBASE-20884
>

Re: Need one more binding vote for 1.3.4 release candidate (RC0)

[Francis Liu]

Hi,

So far this RC has only 2 binding votes, needs one more. I've extended it
until friday (4/26), hopefully we can close this by then.

Thanks!
Francis

Re: [VOTE] The first HBase 1.3.4 release candidate (RC0) is available

[Francis Christopher Liu]

This RC still needs one more binding vote. I'm extending the deadline to
until friday (4/26). Please vote.

Thanks,
Francis

On Fri, Apr 19, 2019 at 1:12 PM Francis Christopher Liu <
toffer@gmail.com> wrote:

> Just a reminder need one more binding vote for this release. So far it's
> mine and Andy's.
>
> Here's my +1
>
> Thanks,
> Francis
>
> On Mon, Apr 15, 2019 at 2:49 PM Andrew Purtell 
> wrote:
>
>> +1
>>
>> Checked sums and signatures: ok
>> RAT check passes: ok (7u80)
>> Built from source: ok (7u80)
>> Unit tests pass: ok (8u172)*
>> 1M row LTT: ok (8u172)
>>
>> * - TestReplicationAdmin failed when run in suite but passed standalone.
>>
>>
>> On Mon, Apr 15, 2019 at 2:10 AM Francis Liu  wrote:
>>
>> > Hi Folks,
>> >
>> > The first HBase 1.3.4 release candidate (RC0) is available for download
>> at
>> > https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/ and Maven
>> > artifacts are available in the temporary repository
>> > *
>> https://repository.apache.org/content/repositories/orgapachehbase-1302/
>> > <
>> https://repository.apache.org/content/repositories/orgapachehbase-1302/>*
>> >
>> > The git tag corresponding to the candidate is '1.3.4RC0' (5d44375).
>> >
>> > A detailed source and binary compatibility report for this release is
>> > available at
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/hbase/hbase-1.3.4RC0/compat-check-report.html
>> > .
>> > Please review and raise any concerns if you have them.
>> >
>> > A list of the 25 issues resolved in this release can be found at
>> >  https://s.apache.org/uyEI .
>> >
>> > Please try out the candidate and vote +1/0/-1.
>> >
>> > Prior to making this announcement I made the following checks:
>> >
>> > RAT check passes (7u211)
>> > Unit test suite passes (7u211)
>> > Loaded the UI in a browser, poked around (8u144)
>> > A few shell commands (8u144)
>> > ITBLL 25M rows (8u144)
>> >
>> > This vote will be open for one week and close April 22, 2018.
>> >
>> > Thanks,
>> > Francis
>> >
>>
>>
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>- A23, Crosstalk
>>
>

[jira] [Created] (HBASE-22305) LRU Block cache may not retain recently used blocks during eviction

[Biju Nair (JIRA)]

Biju Nair created HBASE-22305:
-

 Summary: LRU Block cache may not retain recently used blocks 
during eviction
 Key: HBASE-22305
 URL: https://issues.apache.org/jira/browse/HBASE-22305
 Project: HBase
  Issue Type: Improvement
  Components: BlockCache
Reporter: Biju Nair


During block 
[eviction|https://github.com/apache/hbase/blob/8ec93ea193f6765fd2639ce851ef8cac7df3f555/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java#L628-L648],
 LRU block cache creates LruCachedBlockQueue and adds blocks from the 
Concurrent Hash Map (Cache) to identify the ones for retention. During the 
[add|https://github.com/apache/hbase/blob/8ec93ea193f6765fd2639ce851ef8cac7df3f555/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruCachedBlockQueue.java#L67]
 , entries from the Cache (Hash map) are added to the queue without any check 
on the block access time until total size of blocks added to the queue reaches 
the max size for the queue. After the max size is reached, only blocks with 
[access time greater than the access time of last block in the queue is added 
from "Cache" to the 
queue|https://github.com/apache/hbase/blob/8ec93ea193f6765fd2639ce851ef8cac7df3f555/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruCachedBlockQueue.java#L73].
 
 
But as path of Cache operation, when there is a cache hit the [access time of 
the block is changed to the latest 
time|https://github.com/apache/hbase/blob/8ec93ea193f6765fd2639ce851ef8cac7df3f555/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/LruBlockCache.java#L507].
 While iterating through Cache and adding blocks to the LruCachedBlockQueue, if 
the last element added when the queue size reached max has a access time 
greater than the rest of the blocks in Cache Hash Map, then remaining blocks 
will not be added to the queue to be considered for retention even though they 
have access time greater than other blocks added to the queue before the last 
one. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22304) Fix remaining Checkstyle issues in hbase-endpoint

[Jan Hentschel (JIRA)]

Jan Hentschel created HBASE-22304:
-

 Summary: Fix remaining Checkstyle issues in hbase-endpoint
 Key: HBASE-22304
 URL: https://issues.apache.org/jira/browse/HBASE-22304
 Project: HBase
  Issue Type: Task
Affects Versions: 3.0.0
Reporter: Jan Hentschel
Assignee: Jan Hentschel


The module {{hbase-endpoint}} still has a small number of Checkstyle issues, 
which should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22303) Fix TestReplicationDroppedTables

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-22303:
-

 Summary: Fix TestReplicationDroppedTables
 Key: HBASE-22303
 URL: https://issues.apache.org/jira/browse/HBASE-22303
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang
Assignee: Duo Zhang


It is broken by HBASE-22239...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (HBASE-22302) Fix TestHbck

[Duo Zhang (JIRA)]

Duo Zhang created HBASE-22302:
-

 Summary: Fix TestHbck
 Key: HBASE-22302
 URL: https://issues.apache.org/jira/browse/HBASE-22302
 Project: HBase
  Issue Type: Bug
  Components: test
Reporter: Duo Zhang
Assignee: Duo Zhang






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22299) Documentation has incorrect default number of versions

[Peter Somogyi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Peter Somogyi resolved HBASE-22299.
---
   Resolution: Fixed
Fix Version/s: 3.0.0

Merged PR#189, Thanks [~anis016] for your contribution!

> Documentation has incorrect default number of versions
> --
>
> Key: HBASE-22299
> URL: https://issues.apache.org/jira/browse/HBASE-22299
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Peter Somogyi
>Assignee: Sayed Anisul Hoque
>Priority: Trivial
>  Labels: beginner
> Fix For: 3.0.0
>
>
> Reference guide has this section under 
> [compaction|https://hbase.apache.org/book.html#compaction].
> {quote}
> Compaction and Versions
> When you create a Column Family, you can specify the maximum number of 
> versions to keep, by specifying HColumnDescriptor.setMaxVersions(int 
> versions). The default value is 3. If more versions than the specified 
> maximum exist, the excess versions are filtered out and not written back to 
> the compacted StoreFile.
> {quote}
> This is incorrect, the default value is 1.
> Additionally, HColumnDescriptor is deprecated and the example should use 
> ColumnFamilyDescriptorBuilder$setMaxVersions(int) instead.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] EOL 2.0 release line

[Duo Zhang]

I think we'd better make a 2.0.6 release after 2.2.0 it out, and make sure
that it is fine to upgrade to 2.2.0 from 2.0.6, and then EOL the 2.0.x
release line.

OpenInx  于2019年4月24日周三 下午9:00写道：

> I'v checked the issues in version 2.0.6 [1], seems no critial issues, so
> for me +1.
>
> 1.
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%202.0.6
>
> On Wed, Apr 24, 2019 at 8:37 PM Sean Busbey  wrote:
>
> > Hi folks!
> >
> > Tomorrow will be a month since the 2.0.5 release, which was noted:
> >
> > > NOTICE: We plan on this being the last release on branch-2.0 (unless
> > critical issues found).
> >
> >
> > Any objections to me doing the cleanup + announcement for formally
> > shutting down the release line?
> >
>

Re: [DISCUSS] EOL 2.0 release line

[OpenInx]

I'v checked the issues in version 2.0.6 [1], seems no critial issues, so
for me +1.

1.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20HBASE%20AND%20fixVersion%20%3D%202.0.6

On Wed, Apr 24, 2019 at 8:37 PM Sean Busbey  wrote:

> Hi folks!
>
> Tomorrow will be a month since the 2.0.5 release, which was noted:
>
> > NOTICE: We plan on this being the last release on branch-2.0 (unless
> critical issues found).
>
>
> Any objections to me doing the cleanup + announcement for formally
> shutting down the release line?
>

[DISCUSS] EOL 2.0 release line

[Sean Busbey]

Hi folks!

Tomorrow will be a month since the 2.0.5 release, which was noted:

> NOTICE: We plan on this being the last release on branch-2.0 (unless
critical issues found).


Any objections to me doing the cleanup + announcement for formally
shutting down the release line?

[jira] [Resolved] (HBASE-22272) Fix Checkstyle errors in hbase-backup

[Jan Hentschel (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Hentschel resolved HBASE-22272.
---
   Resolution: Fixed
Fix Version/s: 3.0.0

> Fix Checkstyle errors in hbase-backup
> -
>
> Key: HBASE-22272
> URL: https://issues.apache.org/jira/browse/HBASE-22272
> Project: HBase
>  Issue Type: Task
>Reporter: Jan Hentschel
>Assignee: Jan Hentschel
>Priority: Trivial
> Fix For: 3.0.0
>
>
> There are a few Checkstyle errors in {{hbase-backup}}, which should be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

The second HBase 2.2.0 release candidate (RC2) is available

[Guanghao Zhang]

Please vote on this release candidate (RC) for Apache HBase 2.2.0.
This is the first release of the branch-2.2 line.

The VOTE will remain open for at least 72 hours.

[ ] +1 Release this package as Apache HBase 2.2.0
[ ] -1 Do not release this package because ...

The tag to be voted on is 2.2.0-RC2. The release files, including
signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/

Maven artifacts are available in a staging repository at:

https://repository.apache.org/content/repositories/orgapachehbase-1306/

Signatures used for HBase RCs can be found in this file:
https://dist.apache.org/repos/dist/release/hbase/KEYS

The list of bug fixes going into 2.2.0 can be found in included
CHANGES.md and RELEASENOTES.md available here:
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/CHANGES.md
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/RELEASENOTES.md

A detailed source and binary compatibility report for this release is
available at
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/api_compare_2.2.0RC2_to_2.1.4.html

To learn more about Apache HBase, please see http://hbase.apache.org/

Thanks,
Guanghao Zhang

[VOTE] The second HBase 2.2.0 release candidate (RC2) is available

[Guanghao Zhang]

Please vote on this release candidate (RC) for Apache HBase 2.2.0.
This is the first release of the branch-2.2 line.

The VOTE will remain open for at least 72 hours.

[ ] +1 Release this package as Apache HBase 2.2.0
[ ] -1 Do not release this package because ...

The tag to be voted on is 2.2.0-RC2. The release files, including
signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/

Maven artifacts are available in a staging repository at:

https://repository.apache.org/content/repositories/orgapachehbase-1306/

Signatures used for HBase RCs can be found in this file:
https://dist.apache.org/repos/dist/release/hbase/KEYS

The list of bug fixes going into 2.2.0 can be found in included
CHANGES.md and RELEASENOTES.md available here:
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/CHANGES.md
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/RELEASENOTES.md

A detailed source and binary compatibility report for this release is
available at
https://dist.apache.org/repos/dist/dev/hbase/2.2.0RC2/api_compare_2.2.0RC2_to_2.1.4.html

To learn more about Apache HBase, please see http://hbase.apache.org/

Thanks,
Guanghao Zhang

[jira] [Resolved] (HBASE-22283) Print row and table information when failed to get region location

[Yu Li (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yu Li resolved HBASE-22283.
---
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 1.5.1
   2.2.1
   3.0.0

Merged in:
master: ab3d6cf811
branch-1: 4648ab1db6
branch-2: 54b944a10f

> Print row and table information when failed to get region location
> --
>
> Key: HBASE-22283
> URL: https://issues.apache.org/jira/browse/HBASE-22283
> Project: HBase
>  Issue Type: Improvement
>  Components: Client, logging
>Affects Versions: 1.4.9, 2.0.5, 2.1.4
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Major
> Fix For: 3.0.0, 2.2.1, 1.5.1
>
>
> Currently when failed to get region location, especially when the 
> {{RegionLocations}} returned is null in 
> {{RpcRetryingCallerWithReadReplicas.getRegionLocations}} (we may see more 
> useful message if there's an exception thrown), we only log the replica id 
> w/o any detailed information about row and table, which makes the debugging 
> difficult. Below is an example error message:
> {noformat}
> Caused by: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't 
> get the location for replica 0
>   at 
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:372)
>   at 
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:153)
>   at 
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:58)
>   at 
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:219)
>   at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:277)
>   at 
> org.apache.hadoop.hbase.client.ClientScanner.loadCache(ClientScanner.java:438)
>   at org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:312)
>   at 
> org.apache.hadoop.hbase.MetaTableAccessor.fullScan(MetaTableAccessor.java:639)
>   at 
> org.apache.hadoop.hbase.MetaTableAccessor.tableExists(MetaTableAccessor.java:366)
>   at 
> org.apache.hadoop.hbase.client.HBaseAdmin.tableExists(HBaseAdmin.java:409)
> {noformat}
> And here we propose to improve this part.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (HBASE-22296) Remove TestFromClientSide.testGetStartEndKeysWithRegionReplicas

[Duo Zhang (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HBASE-22296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-22296.
---
  Resolution: Fixed
Assignee: Duo Zhang
Hadoop Flags: Reviewed

Pushed to branch-2.2+.

> Remove TestFromClientSide.testGetStartEndKeysWithRegionReplicas
> ---
>
> Key: HBASE-22296
> URL: https://issues.apache.org/jira/browse/HBASE-22296
> Project: HBase
>  Issue Type: Improvement
>  Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
>
> It tests nothing after HBASE-21753...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)