Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

We have enough affirmative votes to close this vote at the last vote was
over 72 hours ago. If there are any pending tests/votes please let me know.
Otherwise I will be closing this vote tomorrow morning Pacific time.

On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell  wrote:

> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.4.0RC1:
>
> https://github.com/apache/hbase/tree/2.4.0RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
>
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
>
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> The API compatibility report for this RC can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here because Java doesn't consider return type when deciding if
> one method signature duplicates another.
>
> To learn more about Apache HBase, please see
>
> http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>


-- 
Best regards,
Andrew

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

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Stack]

On Thu, Dec 10, 2020 at 2:30 PM Andrew Purtell  wrote:

> Sounds good.
>
> > I would instead
> > suggest bringing a DISCUSS to the dev/private list about Apache HBase
> > adopting Stack's downstreamer project (assuming he's willing to make
> > the donation) and incorporating it into our nightly suite.
>
> Assuming Stack is willing enough to acknowledge the donation we can just
> file a JIRA for this with a link to the github project and discuss further
> in the context of the JIRA, including the IP clearance (
> https://incubator.apache.org/ip-clearance/) process.
>
>
There is almost nothing there (Sean do add some fixups over time though).
As long as he is good w/ it, let me move it over. I'll put up a PR and hunt
him to +1 it.
S


>
> On Thu, Dec 10, 2020 at 1:52 PM Nick Dimiduk  wrote:
>
> > On Thu, Dec 10, 2020 at 12:17 PM Andrew Purtell 
> > wrote:
> > >
> > > Thanks Nick. So we have three dependency related followups?
> >
> > It was my pleasure.
> >
> > > 1. Jetty 9.3 issue with some Java 11 versions. (Possible fix by
> managing
> > up
> > > to Jetty 9.4 transitively.)
> >
> > Jetty dependency is not something I would attempt to "patch" on our
> > side. Instead, if we have a place in our book where we can warn users
> > of various hidden gotchas around HBase, I propose we document it
> > there.
> >
> > > 2. Something with servlet-api as pertains to Spark 1.6.0
> >
> > "pertains to Spark 1.6.0" is speculation on my part. I would instead
> > suggest bringing a DISCUSS to the dev/private list about Apache HBase
> > adopting Stack's downstreamer project (assuming he's willing to make
> > the donation) and incorporating it into our nightly suite. We can
> > shake out whatever specific issues it finds once proper dependency
> > diligence has been conducted.
> >
> > > 3. Exclude zookeeper where we bring in hadoop-common
> >
> > I think this is one we can do. I don't think an issues was raised from
> > this finding after 2.3.0, so I have filed HBASE-25384.
> >
> > > On Thu, Dec 10, 2020 at 11:47 AM Nick Dimiduk 
> > wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > * Signature: ok
> > > > * Checksum : ok
> > > > * Compatibility Report vs 2.3.0: ok
> > > > * Rat check (1.8.0_275 + Hadoop2): ok
> > > >  - mvn clean apache-rat:check
> > > > * Built from source (1.8.0_275+ Hadoop2): ok
> > > >  - mvn clean install  -DskipTests
> > > > * Unit tests pass (1.8.0_275+ Hadoop2): ok
> > > >  - mvn package -P runSmallTests  -Dsurefire.rerunFailingTestsCount=3
> > > > * Rat check (1.8.0_275 + Hadoop3): ok
> > > >  - mvn clean apache-rat:check -D hadoop.profile=3.0
> > > > * Rat check (11.0.8 + Hadoop3): ok
> > > >  - mvn clean apache-rat:check -D hadoop.profile=3.0
> > > > * Built from source (1.8.0_275 + Hadoop3): ok
> > > >  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> > > > * Built from source (11.0.8 + Hadoop3): ok
> > > >  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> > > > * Unit tests pass (1.8.0_275 + Hadoop3): ok
> > > >  - mvn package -P runSmallTests -D hadoop.profile=3.0
> > > > -Dsurefire.rerunFailingTestsCount=3
> > > > * Unit tests pass (11.0.8 + Hadoop3): ok
> > > >  - mvn package -P runSmallTests -D hadoop.profile=3.0
> > > > -Dsurefire.rerunFailingTestsCount=3
> > > > * Unit tests: ok
> > > >  - Jenkins is looking pretty good overall.
> > > >
> > > > * saintstack/hbase-downstreamer: had an issue with servlet api. This
> > > > looks like a transitive class path problem, but I haven't made time
> to
> > > > investigate in further detail; manual inspection of maven
> > > > dependency:tree looks fine, as pertains to the servlet-api jar.
> > > > Looking at that project's dependencies, I'm guessing this means that
> > > > HBase 2.4.0 is not compatible with Spark 1.6.0. For me, this is
> > > > concerning but not a blocker.
> > > >  - mvn -Dhbase.2.version=2.4.0
> > > > -Dhbase.staging.repository='
> > > >
> > https://repository.apache.org/content/repositories/orgapachehbase-1420/'
> > > > -Dhadoop.version=2.10.0 -Dslf4j.version=1.7.30 clean package
> > > >  - had to exclude zookeeper from hadoop-common, which still depends
> on
> > > > zookeeper-3.4.9 and is missing
> > > > org/apache/zookeeper/common/X509Exception$SSLContextException (same
> as
> > > > 2.3.0 release)
> > > >
> > > > On Wed, Dec 9, 2020 at 5:29 PM Nick Dimiduk 
> > wrote:
> > > > >
> > > > > On Wed, Dec 9, 2020 at 5:23 PM Andrew Purtell <
> > andrew.purt...@gmail.com>
> > > > wrote:
> > > > >>
> > > > >> ICYMI, the nightly build passes because the JDK version there has
> > three
> > > > components “11.0.6” and yours fails because your JDK version has four
> > > > components (“11.0.9.1”).
> > > > >
> > > > >
> > > > > Thanks, I did miss this (and I had to look up ICYMI).
> > > > >
> > > > >> As this is a release vote you do not need to withdraw the veto, it
> > does
> > > > not block, but I would ask that you fix your local environment to
> > conform
> > > > the the limitations of Jetty as transitively pulled in via that
>

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Sounds good.

> I would instead
> suggest bringing a DISCUSS to the dev/private list about Apache HBase
> adopting Stack's downstreamer project (assuming he's willing to make
> the donation) and incorporating it into our nightly suite.

Assuming Stack is willing enough to acknowledge the donation we can just
file a JIRA for this with a link to the github project and discuss further
in the context of the JIRA, including the IP clearance (
https://incubator.apache.org/ip-clearance/) process.


On Thu, Dec 10, 2020 at 1:52 PM Nick Dimiduk  wrote:

> On Thu, Dec 10, 2020 at 12:17 PM Andrew Purtell 
> wrote:
> >
> > Thanks Nick. So we have three dependency related followups?
>
> It was my pleasure.
>
> > 1. Jetty 9.3 issue with some Java 11 versions. (Possible fix by managing
> up
> > to Jetty 9.4 transitively.)
>
> Jetty dependency is not something I would attempt to "patch" on our
> side. Instead, if we have a place in our book where we can warn users
> of various hidden gotchas around HBase, I propose we document it
> there.
>
> > 2. Something with servlet-api as pertains to Spark 1.6.0
>
> "pertains to Spark 1.6.0" is speculation on my part. I would instead
> suggest bringing a DISCUSS to the dev/private list about Apache HBase
> adopting Stack's downstreamer project (assuming he's willing to make
> the donation) and incorporating it into our nightly suite. We can
> shake out whatever specific issues it finds once proper dependency
> diligence has been conducted.
>
> > 3. Exclude zookeeper where we bring in hadoop-common
>
> I think this is one we can do. I don't think an issues was raised from
> this finding after 2.3.0, so I have filed HBASE-25384.
>
> > On Thu, Dec 10, 2020 at 11:47 AM Nick Dimiduk 
> wrote:
> >
> > > +1 (binding)
> > >
> > > * Signature: ok
> > > * Checksum : ok
> > > * Compatibility Report vs 2.3.0: ok
> > > * Rat check (1.8.0_275 + Hadoop2): ok
> > >  - mvn clean apache-rat:check
> > > * Built from source (1.8.0_275+ Hadoop2): ok
> > >  - mvn clean install  -DskipTests
> > > * Unit tests pass (1.8.0_275+ Hadoop2): ok
> > >  - mvn package -P runSmallTests  -Dsurefire.rerunFailingTestsCount=3
> > > * Rat check (1.8.0_275 + Hadoop3): ok
> > >  - mvn clean apache-rat:check -D hadoop.profile=3.0
> > > * Rat check (11.0.8 + Hadoop3): ok
> > >  - mvn clean apache-rat:check -D hadoop.profile=3.0
> > > * Built from source (1.8.0_275 + Hadoop3): ok
> > >  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> > > * Built from source (11.0.8 + Hadoop3): ok
> > >  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> > > * Unit tests pass (1.8.0_275 + Hadoop3): ok
> > >  - mvn package -P runSmallTests -D hadoop.profile=3.0
> > > -Dsurefire.rerunFailingTestsCount=3
> > > * Unit tests pass (11.0.8 + Hadoop3): ok
> > >  - mvn package -P runSmallTests -D hadoop.profile=3.0
> > > -Dsurefire.rerunFailingTestsCount=3
> > > * Unit tests: ok
> > >  - Jenkins is looking pretty good overall.
> > >
> > > * saintstack/hbase-downstreamer: had an issue with servlet api. This
> > > looks like a transitive class path problem, but I haven't made time to
> > > investigate in further detail; manual inspection of maven
> > > dependency:tree looks fine, as pertains to the servlet-api jar.
> > > Looking at that project's dependencies, I'm guessing this means that
> > > HBase 2.4.0 is not compatible with Spark 1.6.0. For me, this is
> > > concerning but not a blocker.
> > >  - mvn -Dhbase.2.version=2.4.0
> > > -Dhbase.staging.repository='
> > >
> https://repository.apache.org/content/repositories/orgapachehbase-1420/'
> > > -Dhadoop.version=2.10.0 -Dslf4j.version=1.7.30 clean package
> > >  - had to exclude zookeeper from hadoop-common, which still depends on
> > > zookeeper-3.4.9 and is missing
> > > org/apache/zookeeper/common/X509Exception$SSLContextException (same as
> > > 2.3.0 release)
> > >
> > > On Wed, Dec 9, 2020 at 5:29 PM Nick Dimiduk 
> wrote:
> > > >
> > > > On Wed, Dec 9, 2020 at 5:23 PM Andrew Purtell <
> andrew.purt...@gmail.com>
> > > wrote:
> > > >>
> > > >> ICYMI, the nightly build passes because the JDK version there has
> three
> > > components “11.0.6” and yours fails because your JDK version has four
> > > components (“11.0.9.1”).
> > > >
> > > >
> > > > Thanks, I did miss this (and I had to look up ICYMI).
> > > >
> > > >> As this is a release vote you do not need to withdraw the veto, it
> does
> > > not block, but I would ask that you fix your local environment to
> conform
> > > the the limitations of Jetty as transitively pulled in via that
> optional
> > > profile and retest. This is not an HBase issue and it should not be
> > > relevant in voting. (IMHO)
> > > >
> > > >
> > > > Since this is indeed a jetty issue, I agree that this is not an HBase
> > > issue and I rescind the -1. Let me grab a slightly different JDK11
> build
> > > and resume my evaluation.
> > > >
> > > >> > On Dec 9, 2020, at 5:10 PM, Andrew Purtell <
> andrew.purt...@gmail.com>
> > > wrote:
> > > >> >
> > > >> > Nic

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

On Thu, Dec 10, 2020 at 12:17 PM Andrew Purtell  wrote:
>
> Thanks Nick. So we have three dependency related followups?

It was my pleasure.

> 1. Jetty 9.3 issue with some Java 11 versions. (Possible fix by managing up
> to Jetty 9.4 transitively.)

Jetty dependency is not something I would attempt to "patch" on our
side. Instead, if we have a place in our book where we can warn users
of various hidden gotchas around HBase, I propose we document it
there.

> 2. Something with servlet-api as pertains to Spark 1.6.0

"pertains to Spark 1.6.0" is speculation on my part. I would instead
suggest bringing a DISCUSS to the dev/private list about Apache HBase
adopting Stack's downstreamer project (assuming he's willing to make
the donation) and incorporating it into our nightly suite. We can
shake out whatever specific issues it finds once proper dependency
diligence has been conducted.

> 3. Exclude zookeeper where we bring in hadoop-common

I think this is one we can do. I don't think an issues was raised from
this finding after 2.3.0, so I have filed HBASE-25384.

> On Thu, Dec 10, 2020 at 11:47 AM Nick Dimiduk  wrote:
>
> > +1 (binding)
> >
> > * Signature: ok
> > * Checksum : ok
> > * Compatibility Report vs 2.3.0: ok
> > * Rat check (1.8.0_275 + Hadoop2): ok
> >  - mvn clean apache-rat:check
> > * Built from source (1.8.0_275+ Hadoop2): ok
> >  - mvn clean install  -DskipTests
> > * Unit tests pass (1.8.0_275+ Hadoop2): ok
> >  - mvn package -P runSmallTests  -Dsurefire.rerunFailingTestsCount=3
> > * Rat check (1.8.0_275 + Hadoop3): ok
> >  - mvn clean apache-rat:check -D hadoop.profile=3.0
> > * Rat check (11.0.8 + Hadoop3): ok
> >  - mvn clean apache-rat:check -D hadoop.profile=3.0
> > * Built from source (1.8.0_275 + Hadoop3): ok
> >  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> > * Built from source (11.0.8 + Hadoop3): ok
> >  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> > * Unit tests pass (1.8.0_275 + Hadoop3): ok
> >  - mvn package -P runSmallTests -D hadoop.profile=3.0
> > -Dsurefire.rerunFailingTestsCount=3
> > * Unit tests pass (11.0.8 + Hadoop3): ok
> >  - mvn package -P runSmallTests -D hadoop.profile=3.0
> > -Dsurefire.rerunFailingTestsCount=3
> > * Unit tests: ok
> >  - Jenkins is looking pretty good overall.
> >
> > * saintstack/hbase-downstreamer: had an issue with servlet api. This
> > looks like a transitive class path problem, but I haven't made time to
> > investigate in further detail; manual inspection of maven
> > dependency:tree looks fine, as pertains to the servlet-api jar.
> > Looking at that project's dependencies, I'm guessing this means that
> > HBase 2.4.0 is not compatible with Spark 1.6.0. For me, this is
> > concerning but not a blocker.
> >  - mvn -Dhbase.2.version=2.4.0
> > -Dhbase.staging.repository='
> > https://repository.apache.org/content/repositories/orgapachehbase-1420/'
> > -Dhadoop.version=2.10.0 -Dslf4j.version=1.7.30 clean package
> >  - had to exclude zookeeper from hadoop-common, which still depends on
> > zookeeper-3.4.9 and is missing
> > org/apache/zookeeper/common/X509Exception$SSLContextException (same as
> > 2.3.0 release)
> >
> > On Wed, Dec 9, 2020 at 5:29 PM Nick Dimiduk  wrote:
> > >
> > > On Wed, Dec 9, 2020 at 5:23 PM Andrew Purtell 
> > wrote:
> > >>
> > >> ICYMI, the nightly build passes because the JDK version there has three
> > components “11.0.6” and yours fails because your JDK version has four
> > components (“11.0.9.1”).
> > >
> > >
> > > Thanks, I did miss this (and I had to look up ICYMI).
> > >
> > >> As this is a release vote you do not need to withdraw the veto, it does
> > not block, but I would ask that you fix your local environment to conform
> > the the limitations of Jetty as transitively pulled in via that optional
> > profile and retest. This is not an HBase issue and it should not be
> > relevant in voting. (IMHO)
> > >
> > >
> > > Since this is indeed a jetty issue, I agree that this is not an HBase
> > issue and I rescind the -1. Let me grab a slightly different JDK11 build
> > and resume my evaluation.
> > >
> > >> > On Dec 9, 2020, at 5:10 PM, Andrew Purtell 
> > wrote:
> > >> >
> > >> > Nick,
> > >> >
> > >> > Given the nature of this issue I’d ask you to try Duo’s suggestion
> > and if an earlier version of Hadoop 3 succeeds that this be sufficient this
> > time around.
> > >> >
> > >> > All,
> > >> >
> > >> > I will start a DISCUSS thread as follow up as to what should be
> > considered required and veto worthy for a RC and what should not, with
> > regard to optional build profiles. In my opinion ‘required‘ should be
> > defined as what is enabled by default in the release build, and ‘optional’
> > is everything else until we agree to specifically include one or more
> > optional build profiles to the required list.
> > >> >
> > >> >
> > >> >> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
> > >> >>
> > >> >> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> > >> >> implementation for 9

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Thanks Nick. So we have three dependency related followups?
1. Jetty 9.3 issue with some Java 11 versions. (Possible fix by managing up
to Jetty 9.4 transitively.)
2. Something with servlet-api as pertains to Spark 1.6.0
3. Exclude zookeeper where we bring in hadoop-common
Would you mind filing JIRAs for these if we don't have them and set fix
version to 2.4.1 (at least)? You have more context than I on #2 and #3.



On Thu, Dec 10, 2020 at 11:47 AM Nick Dimiduk  wrote:

> +1 (binding)
>
> * Signature: ok
> * Checksum : ok
> * Compatibility Report vs 2.3.0: ok
> * Rat check (1.8.0_275 + Hadoop2): ok
>  - mvn clean apache-rat:check
> * Built from source (1.8.0_275+ Hadoop2): ok
>  - mvn clean install  -DskipTests
> * Unit tests pass (1.8.0_275+ Hadoop2): ok
>  - mvn package -P runSmallTests  -Dsurefire.rerunFailingTestsCount=3
> * Rat check (1.8.0_275 + Hadoop3): ok
>  - mvn clean apache-rat:check -D hadoop.profile=3.0
> * Rat check (11.0.8 + Hadoop3): ok
>  - mvn clean apache-rat:check -D hadoop.profile=3.0
> * Built from source (1.8.0_275 + Hadoop3): ok
>  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> * Built from source (11.0.8 + Hadoop3): ok
>  - mvn clean install -D hadoop.profile=3.0 -DskipTests
> * Unit tests pass (1.8.0_275 + Hadoop3): ok
>  - mvn package -P runSmallTests -D hadoop.profile=3.0
> -Dsurefire.rerunFailingTestsCount=3
> * Unit tests pass (11.0.8 + Hadoop3): ok
>  - mvn package -P runSmallTests -D hadoop.profile=3.0
> -Dsurefire.rerunFailingTestsCount=3
> * Unit tests: ok
>  - Jenkins is looking pretty good overall.
>
> * saintstack/hbase-downstreamer: had an issue with servlet api. This
> looks like a transitive class path problem, but I haven't made time to
> investigate in further detail; manual inspection of maven
> dependency:tree looks fine, as pertains to the servlet-api jar.
> Looking at that project's dependencies, I'm guessing this means that
> HBase 2.4.0 is not compatible with Spark 1.6.0. For me, this is
> concerning but not a blocker.
>  - mvn -Dhbase.2.version=2.4.0
> -Dhbase.staging.repository='
> https://repository.apache.org/content/repositories/orgapachehbase-1420/'
> -Dhadoop.version=2.10.0 -Dslf4j.version=1.7.30 clean package
>  - had to exclude zookeeper from hadoop-common, which still depends on
> zookeeper-3.4.9 and is missing
> org/apache/zookeeper/common/X509Exception$SSLContextException (same as
> 2.3.0 release)
>
> On Wed, Dec 9, 2020 at 5:29 PM Nick Dimiduk  wrote:
> >
> > On Wed, Dec 9, 2020 at 5:23 PM Andrew Purtell 
> wrote:
> >>
> >> ICYMI, the nightly build passes because the JDK version there has three
> components “11.0.6” and yours fails because your JDK version has four
> components (“11.0.9.1”).
> >
> >
> > Thanks, I did miss this (and I had to look up ICYMI).
> >
> >> As this is a release vote you do not need to withdraw the veto, it does
> not block, but I would ask that you fix your local environment to conform
> the the limitations of Jetty as transitively pulled in via that optional
> profile and retest. This is not an HBase issue and it should not be
> relevant in voting. (IMHO)
> >
> >
> > Since this is indeed a jetty issue, I agree that this is not an HBase
> issue and I rescind the -1. Let me grab a slightly different JDK11 build
> and resume my evaluation.
> >
> >> > On Dec 9, 2020, at 5:10 PM, Andrew Purtell 
> wrote:
> >> >
> >> > Nick,
> >> >
> >> > Given the nature of this issue I’d ask you to try Duo’s suggestion
> and if an earlier version of Hadoop 3 succeeds that this be sufficient this
> time around.
> >> >
> >> > All,
> >> >
> >> > I will start a DISCUSS thread as follow up as to what should be
> considered required and veto worthy for a RC and what should not, with
> regard to optional build profiles. In my opinion ‘required‘ should be
> defined as what is enabled by default in the release build, and ‘optional’
> is everything else until we agree to specifically include one or more
> optional build profiles to the required list.
> >> >
> >> >
> >> >> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
> >> >>
> >> >> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> >> >> implementation for 9.3 and 9.4 are completely different, there is no
> >> >> problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can
> only pass
> >> >> version with two dots, i.e, 11.0.9.
> >> >>
> >> >> I think you could add -Dhadoop-three.version to set the hadoop 3
> version
> >> >> explicitly to a newer version which uses jetty 9.4 to solve the
> problem,
> >> >> IIRC all the newest release for each active release line has upgrade
> to
> >> >> jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4
> are
> >> >> incompatible.
> >> >>
> >> >> Thanks.
> >> >>
> >> >> 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
> >> >>
> >> >>> On nightly jdk11 build the jdk version is
> >> >>>
> >> >>> AdoptOpenJDK-11.0.6+10
> >> >>>
> >> >>> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> >> >>>
> >>  Let me rephrase.
> >> 
> >>  I'm 

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

+1 (binding)

* Signature: ok
* Checksum : ok
* Compatibility Report vs 2.3.0: ok
* Rat check (1.8.0_275 + Hadoop2): ok
 - mvn clean apache-rat:check
* Built from source (1.8.0_275+ Hadoop2): ok
 - mvn clean install  -DskipTests
* Unit tests pass (1.8.0_275+ Hadoop2): ok
 - mvn package -P runSmallTests  -Dsurefire.rerunFailingTestsCount=3
* Rat check (1.8.0_275 + Hadoop3): ok
 - mvn clean apache-rat:check -D hadoop.profile=3.0
* Rat check (11.0.8 + Hadoop3): ok
 - mvn clean apache-rat:check -D hadoop.profile=3.0
* Built from source (1.8.0_275 + Hadoop3): ok
 - mvn clean install -D hadoop.profile=3.0 -DskipTests
* Built from source (11.0.8 + Hadoop3): ok
 - mvn clean install -D hadoop.profile=3.0 -DskipTests
* Unit tests pass (1.8.0_275 + Hadoop3): ok
 - mvn package -P runSmallTests -D hadoop.profile=3.0
-Dsurefire.rerunFailingTestsCount=3
* Unit tests pass (11.0.8 + Hadoop3): ok
 - mvn package -P runSmallTests -D hadoop.profile=3.0
-Dsurefire.rerunFailingTestsCount=3
* Unit tests: ok
 - Jenkins is looking pretty good overall.

* saintstack/hbase-downstreamer: had an issue with servlet api. This
looks like a transitive class path problem, but I haven't made time to
investigate in further detail; manual inspection of maven
dependency:tree looks fine, as pertains to the servlet-api jar.
Looking at that project's dependencies, I'm guessing this means that
HBase 2.4.0 is not compatible with Spark 1.6.0. For me, this is
concerning but not a blocker.
 - mvn -Dhbase.2.version=2.4.0
-Dhbase.staging.repository='https://repository.apache.org/content/repositories/orgapachehbase-1420/'
-Dhadoop.version=2.10.0 -Dslf4j.version=1.7.30 clean package
 - had to exclude zookeeper from hadoop-common, which still depends on
zookeeper-3.4.9 and is missing
org/apache/zookeeper/common/X509Exception$SSLContextException (same as
2.3.0 release)

On Wed, Dec 9, 2020 at 5:29 PM Nick Dimiduk  wrote:
>
> On Wed, Dec 9, 2020 at 5:23 PM Andrew Purtell  
> wrote:
>>
>> ICYMI, the nightly build passes because the JDK version there has three 
>> components “11.0.6” and yours fails because your JDK version has four 
>> components (“11.0.9.1”).
>
>
> Thanks, I did miss this (and I had to look up ICYMI).
>
>> As this is a release vote you do not need to withdraw the veto, it does not 
>> block, but I would ask that you fix your local environment to conform the 
>> the limitations of Jetty as transitively pulled in via that optional profile 
>> and retest. This is not an HBase issue and it should not be relevant in 
>> voting. (IMHO)
>
>
> Since this is indeed a jetty issue, I agree that this is not an HBase issue 
> and I rescind the -1. Let me grab a slightly different JDK11 build and resume 
> my evaluation.
>
>> > On Dec 9, 2020, at 5:10 PM, Andrew Purtell  
>> > wrote:
>> >
>> > Nick,
>> >
>> > Given the nature of this issue I’d ask you to try Duo’s suggestion and if 
>> > an earlier version of Hadoop 3 succeeds that this be sufficient this time 
>> > around.
>> >
>> > All,
>> >
>> > I will start a DISCUSS thread as follow up as to what should be considered 
>> > required and veto worthy for a RC and what should not, with regard to 
>> > optional build profiles. In my opinion ‘required‘ should be defined as 
>> > what is enabled by default in the release build, and ‘optional’ is 
>> > everything else until we agree to specifically include one or more 
>> > optional build profiles to the required list.
>> >
>> >
>> >> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
>> >>
>> >> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
>> >> implementation for 9.3 and 9.4 are completely different, there is no
>> >> problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only 
>> >> pass
>> >> version with two dots, i.e, 11.0.9.
>> >>
>> >> I think you could add -Dhadoop-three.version to set the hadoop 3 version
>> >> explicitly to a newer version which uses jetty 9.4 to solve the problem,
>> >> IIRC all the newest release for each active release line has upgrade to
>> >> jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
>> >> incompatible.
>> >>
>> >> Thanks.
>> >>
>> >> 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
>> >>
>> >>> On nightly jdk11 build the jdk version is
>> >>>
>> >>> AdoptOpenJDK-11.0.6+10
>> >>>
>> >>> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
>> >>>
>>  Let me rephrase.
>> 
>>  I'm all for testing the optional configurations. I'm less supportive of
>>  vetoing releases when an optional configuration has some issue due to a
>>  third party component. I would like to see us veto only on the required
>>  configurations, and otherwise file JIRAs to fix up the nits on the
>>  optional
>>  ones.
>> 
>> 
>>  On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
>>  wrote:
>> 
>> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>> >
>> > So unless I am mistaken, some Jetty utility class is not able to parse
>>  the
>> > version string of you

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Duo Zhang]

Never mind. Hope this could solve your problem.

Nick Dimiduk  于2020年12月10日周四 上午9:33写道：

> On Wed, Dec 9, 2020 at 5:30 PM 张铎(Duo Zhang) 
> wrote:
>
> > I've explained to you why the nightly build has no problem...
> >
> > It is because we use 11.0.6 for nightly, while your jdk version is
> > 11.0.9.1, the JavaVersion class in jetty 9.3 can only pass the former
> > one...
> >
>
> Yes, I see that now (and I have read the offending Jetty code). My
> apologies, Duo, for speaking past your earlier comment.
>
> Nick Dimiduk  于2020年12月10日周四 上午9:10写道：
> >
> > > Rather than have a user rebuild HBase for themselves and specify
> > > hadoop-three.version, why not bump the Hadoop3 version in our POM?
> > >
> > > I also don't have an explanation for why the JDK11 + Hadoop3 build
> > succeeds
> > > in Jenkins. The branch-2.4 build isn't downloading a flakey tests list,
> > so
> > > I don't think these tests are being excluded. In fact, Jenkins records
> a
> > > successful execution of this test on JDK11/Hadoop3.
> > >
> > >
> > >
> >
> https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/4/testReport/org.apache.hadoop.hbase.regionserver.wal/TestAsyncProtobufLog/
> > >
> > > On Wed, Dec 9, 2020 at 4:31 PM 张铎(Duo Zhang) 
> > > wrote:
> > >
> > > > OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> > > > implementation for 9.3 and 9.4 are completely different, there is no
> > > > problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can
> only
> > > pass
> > > > version with two dots, i.e, 11.0.9.
> > > >
> > > > I think you could add -Dhadoop-three.version to set the hadoop 3
> > version
> > > > explicitly to a newer version which uses jetty 9.4 to solve the
> > problem,
> > > > IIRC all the newest release for each active release line has upgrade
> to
> > > > jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4
> > are
> > > > incompatible.
> > > >
> > > > Thanks.
> > > >
> > > > 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
> > > >
> > > > > On nightly jdk11 build the jdk version is
> > > > >
> > > > > AdoptOpenJDK-11.0.6+10
> > > > >
> > > > > Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> > > > >
> > > > >> Let me rephrase.
> > > > >>
> > > > >> I'm all for testing the optional configurations. I'm less
> supportive
> > > of
> > > > >> vetoing releases when an optional configuration has some issue due
> > to
> > > a
> > > > >> third party component. I would like to see us veto only on the
> > > required
> > > > >> configurations, and otherwise file JIRAs to fix up the nits on the
> > > > >> optional
> > > > >> ones.
> > > > >>
> > > > >>
> > > > >> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell <
> apurt...@apache.org>
> > > > >> wrote:
> > > > >>
> > > > >> > > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> > > > >> >
> > > > >> > So unless I am mistaken, some Jetty utility class is not able to
> > > parse
> > > > >> the
> > > > >> > version string of your particular JDK/JRE.
> > > > >> >
> > > > >> > We can try to downgrade Jetty but I am not sure in general how
> we
> > > are
> > > > >> > supposed to take on the risk of third party dependencies doing
> the
> > > > wrong
> > > > >> > thing in an optional configuration. I for one do not want to
> deal
> > > > with a
> > > > >> > combinatorial explosion of transitive dependencies when
> releasing.
> > > > >> >
> > > > >> >
> > > > >> > On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk <
> ndimi...@apache.org>
> > > > >> wrote:
> > > > >> >
> > > > >> >> This is coming out of Jetty + Hadoop. This build has a
> regression
> > > in
> > > > >> our
> > > > >> >> JDK11 support. Or perhaps there's a regression in the upstream
> > > Hadoop
> > > > >> >> against which JDK11 builds.
> > > > >> >>
> > > > >> >> I'm afraid I must vote -1 until we can sort out the issue. I'd
> > > > >> appreciate
> > > > >> >> it if someone else can attempt to repro, help ensure it's not
> > just
> > > > me.
> > > > >> >>
> > > > >> >> Thanks,
> > > > >> >> Nick
> > > > >> >>
> > > > >> >> (Apologies for the crude stack trace; this is copied out of an
> > > > attached
> > > > >> >> debugger)
> > > > >> >>
> > > > >> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> > > > >> >> parse:49, JavaVersion (org.eclipse.jetty.util)
> > > > >> >> :43, JavaVersion (org.eclipse.jetty.util)
> > > > >> >> findAndFilterContainerPaths:185, WebInfConfiguration
> > > > >> >> (org.eclipse.jetty.webapp)
> > > > >> >> preConfigure:155, WebInfConfiguration
> (org.eclipse.jetty.webapp)
> > > > >> >> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> > > > >> >> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> > > > >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > > > >> >> start:131, ContainerLifeCycle
> (org.eclipse.jetty.util.component)
> > > > >> >> doStart:113, ContainerLifeCycle
> > (org.eclipse.jetty.util.component)
> > > > >> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> > > > >> >> start:68, Abstrac

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

The staging repository is now
https://repository.apache.org/content/repositories/orgapachehbase-1420/ .
Should this vote pass, this is the repository that will be released.

This repo does not contain the unwanted .asc.asc files found earlier. Other
staging repos have been dropped.

On Fri, Dec 4, 2020 at 9:29 AM Andrew Purtell  wrote:

> The temporary Maven repository is now available at
>
>
> https://repository.apache.org/content/repositories/orgapachehbase-1416/ .
>
> On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell  wrote:
>
>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>>
>> The VOTE will remain open for at least 72 hours.
>>
>> [ ] +1 Release this package as Apache hbase 2.4.0
>> [ ] -1 Do not release this package because ...
>>
>> The tag to be voted on is 2.4.0RC1:
>>
>> https://github.com/apache/hbase/tree/2.4.0RC1
>>
>> The release files, including signatures, digests, as well as CHANGES.md
>> and RELEASENOTES.md included in this RC can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>>
>> Customarily Maven artifacts would be available in a staging repository.
>> Unfortunately I was forced to terminate the Maven deploy step after
>> the upload ran for more than four hours and my build equipment
>> needed to be relocated, with loss of network connectivity. This RC has
>> been delayed long enough. A temporary Maven repository is not a
>> requirement for a vote. I will retry Maven deploy tomorrow. I can
>> promise the artifacts for this RC will be staged in Apache Nexus and
>> ready for release well ahead of the earliest possible time this vote
>> can complete.
>>
>> Artifacts were signed with the apurt...@apache.org key which can be found
>> in:
>>
>> https://dist.apache.org/repos/dist/release/hbase/KEYS
>>
>> The API compatibility report for this RC can be found at:
>>
>>
>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>>
>> The changes are mostly added methods, which conform to the compatibility
>> guidelines for a new minor release. There is one change to the public
>> Region interface that alters the return type of a method. This is
>> equivalent to a removal then addition and can be a binary compatibility
>> problem. However to your RM's eye the change looks intentional and is
>> part of an API improvement project, and a compatibility method is not
>> possible here because Java doesn't consider return type when deciding if
>> one method signature duplicates another.
>>
>> To learn more about Apache HBase, please see
>>
>> http://hbase.apache.org/
>>
>> Thanks,
>> Your HBase Release Manager
>>
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>


-- 
Best regards,
Andrew

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

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Just to clarify, since this thread had forked:

- I want to discuss what a RM should check for a RC. There should be a list of 
required build profiles in the documentation. That will help a lot. I will 
start a DISCUSS when the saga of this vote wraps up. 

- I accept that if there is a blocking problem with Java 11 support the RC 
should fail. Apologies for missing earlier discussion. 

- Nick has an environmental issue impacting his ability to test (his JDK has 
four version components, which Jetty 9.3, as transitively pulled in, does not 
support). I’ve asked him to switch JDK accordingly and retest as this is not an 
HBase issue. It is an integration problem one step removed with an easy 
mitigation so is not a release blocker. As such i won’t be withdrawing the RC 
over this. Of course this should be fixed with a follow up JIRA. 


> On Dec 9, 2020, at 5:26 PM, Andrew Purtell  wrote:
> 
> So does the RM documentation need update to tell the RM that all supported 
> configurations should be tested? Should the release script run through them? 
> 
> This is new to me because I’ve been on branch-1 forever so it’s like newbie 
> feedback. :-) Java 11 and Hadoop 3 stuff being a potential blocker is 
> surprising. I missed the earlier discussion. 
> 
> 
>>> On Dec 9, 2020, at 5:22 PM, Nick Dimiduk  wrote:
>>> 
>>> On Wed, Dec 9, 2020 at 5:11 PM Andrew Purtell 
>>> wrote:
>>> 
>>> Given the nature of this issue I’d ask you to try Duo’s suggestion and if
>>> an earlier version of Hadoop 3 succeeds that this be sufficient this time
>>> around.
>>> 
>> 
>> The only version of Hadoop3 we've supported for JDK11 is Hadoop3.2. Hadoop3
>> version specified in the pom has not changed since 2.3.0. I can try the
>> local build against the newer Hadoop 3.3.0, but that doesn't change this
>> being a regression.
>> 
>> It also occurs to me that perhaps classpath order is at play here, and
>> there are different versions of maven in different environments. I haven't
>> investigated this yet.
>> 
>> All,
>>> 
>>> I will start a DISCUSS thread as follow up as to what should be considered
>>> required and veto worthy for a RC and what should not, with regard to
>>> optional build profiles. In my opinion ‘required‘ should be defined as what
>>> is enabled by default in the release build, and ‘optional’ is everything
>>> else until we agree to specifically include one or more optional build
>>> profiles to the required list.
>>> 
>> 
>> To the best of my knowledge, JDK11 is not an optional release profile.
>> Preliminary support for JDK11 was introduced in 2.3 as a supported
>> configuration, and both our book and our build infrastructure were extended
>> accordingly. My understanding is that this discussion was settled in the
>> lead up to 2.3.0.
>> 
>> https://hbase.apache.org/book.html#java
>> https://hbase.apache.org/book.html#hadoop
>> 
 On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
 
 OK, I think the problem is a bug in jetty 9.3, the JavaVersion
 implementation for 9.3 and 9.4 are completely different, there is no
 problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only
>>> pass
 version with two dots, i.e, 11.0.9.
 
 I think you could add -Dhadoop-three.version to set the hadoop 3 version
 explicitly to a newer version which uses jetty 9.4 to solve the problem,
 IIRC all the newest release for each active release line has upgrade to
 jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
 incompatible.
 
 Thanks.
 
 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
 
> On nightly jdk11 build the jdk version is
> 
> AdoptOpenJDK-11.0.6+10
> 
> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> 
>> Let me rephrase.
>> 
>> I'm all for testing the optional configurations. I'm less supportive of
>> vetoing releases when an optional configuration has some issue due to a
>> third party component. I would like to see us veto only on the required
>> configurations, and otherwise file JIRAs to fix up the nits on the
>> optional
>> ones.
>> 
>> 
>> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
>> wrote:
>> 
 parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>>> 
>>> So unless I am mistaken, some Jetty utility class is not able to parse
>> the
>>> version string of your particular JDK/JRE.
>>> 
>>> We can try to downgrade Jetty but I am not sure in general how we are
>>> supposed to take on the risk of third party dependencies doing the
>>> wrong
>>> thing in an optional configuration. I for one do not want to deal
>>> with a
>>> combinatorial explosion of transitive dependencies when releasing.
>>> 
>>> 
>>> On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
>> wrote:
>>> 
 This is coming out of Jetty + Hadoop. This build has a regression in
>> our
 JDK11 support. Or perhaps there's a regression in t

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

On Wed, Dec 9, 2020 at 5:30 PM 张铎(Duo Zhang)  wrote:

> I've explained to you why the nightly build has no problem...
>
> It is because we use 11.0.6 for nightly, while your jdk version is
> 11.0.9.1, the JavaVersion class in jetty 9.3 can only pass the former
> one...
>

Yes, I see that now (and I have read the offending Jetty code). My
apologies, Duo, for speaking past your earlier comment.

Nick Dimiduk  于2020年12月10日周四 上午9:10写道：
>
> > Rather than have a user rebuild HBase for themselves and specify
> > hadoop-three.version, why not bump the Hadoop3 version in our POM?
> >
> > I also don't have an explanation for why the JDK11 + Hadoop3 build
> succeeds
> > in Jenkins. The branch-2.4 build isn't downloading a flakey tests list,
> so
> > I don't think these tests are being excluded. In fact, Jenkins records a
> > successful execution of this test on JDK11/Hadoop3.
> >
> >
> >
> https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/4/testReport/org.apache.hadoop.hbase.regionserver.wal/TestAsyncProtobufLog/
> >
> > On Wed, Dec 9, 2020 at 4:31 PM 张铎(Duo Zhang) 
> > wrote:
> >
> > > OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> > > implementation for 9.3 and 9.4 are completely different, there is no
> > > problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only
> > pass
> > > version with two dots, i.e, 11.0.9.
> > >
> > > I think you could add -Dhadoop-three.version to set the hadoop 3
> version
> > > explicitly to a newer version which uses jetty 9.4 to solve the
> problem,
> > > IIRC all the newest release for each active release line has upgrade to
> > > jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4
> are
> > > incompatible.
> > >
> > > Thanks.
> > >
> > > 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
> > >
> > > > On nightly jdk11 build the jdk version is
> > > >
> > > > AdoptOpenJDK-11.0.6+10
> > > >
> > > > Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> > > >
> > > >> Let me rephrase.
> > > >>
> > > >> I'm all for testing the optional configurations. I'm less supportive
> > of
> > > >> vetoing releases when an optional configuration has some issue due
> to
> > a
> > > >> third party component. I would like to see us veto only on the
> > required
> > > >> configurations, and otherwise file JIRAs to fix up the nits on the
> > > >> optional
> > > >> ones.
> > > >>
> > > >>
> > > >> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
> > > >> wrote:
> > > >>
> > > >> > > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> > > >> >
> > > >> > So unless I am mistaken, some Jetty utility class is not able to
> > parse
> > > >> the
> > > >> > version string of your particular JDK/JRE.
> > > >> >
> > > >> > We can try to downgrade Jetty but I am not sure in general how we
> > are
> > > >> > supposed to take on the risk of third party dependencies doing the
> > > wrong
> > > >> > thing in an optional configuration. I for one do not want to deal
> > > with a
> > > >> > combinatorial explosion of transitive dependencies when releasing.
> > > >> >
> > > >> >
> > > >> > On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
> > > >> wrote:
> > > >> >
> > > >> >> This is coming out of Jetty + Hadoop. This build has a regression
> > in
> > > >> our
> > > >> >> JDK11 support. Or perhaps there's a regression in the upstream
> > Hadoop
> > > >> >> against which JDK11 builds.
> > > >> >>
> > > >> >> I'm afraid I must vote -1 until we can sort out the issue. I'd
> > > >> appreciate
> > > >> >> it if someone else can attempt to repro, help ensure it's not
> just
> > > me.
> > > >> >>
> > > >> >> Thanks,
> > > >> >> Nick
> > > >> >>
> > > >> >> (Apologies for the crude stack trace; this is copied out of an
> > > attached
> > > >> >> debugger)
> > > >> >>
> > > >> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> > > >> >> parse:49, JavaVersion (org.eclipse.jetty.util)
> > > >> >> :43, JavaVersion (org.eclipse.jetty.util)
> > > >> >> findAndFilterContainerPaths:185, WebInfConfiguration
> > > >> >> (org.eclipse.jetty.webapp)
> > > >> >> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> > > >> >> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> > > >> >> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> > > >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > > >> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > > >> >> doStart:113, ContainerLifeCycle
> (org.eclipse.jetty.util.component)
> > > >> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> > > >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > > >> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > > >> >> start:427, Server (org.eclipse.jetty.server)
> > > >> >> doStart:105, ContainerLifeCycle
> (org.eclipse.jetty.util.component)
> > > >> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> > > >> >> doStart:394, Server (org.eclipse.jetty.server)
> > > >> >> start

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Duo Zhang]

I've explained to you why the nightly build has no problem...

It is because we use 11.0.6 for nightly, while your jdk version is
11.0.9.1, the JavaVersion class in jetty 9.3 can only pass the former one...

Nick Dimiduk  于2020年12月10日周四 上午9:10写道：

> Rather than have a user rebuild HBase for themselves and specify
> hadoop-three.version, why not bump the Hadoop3 version in our POM?
>
> I also don't have an explanation for why the JDK11 + Hadoop3 build succeeds
> in Jenkins. The branch-2.4 build isn't downloading a flakey tests list, so
> I don't think these tests are being excluded. In fact, Jenkins records a
> successful execution of this test on JDK11/Hadoop3.
>
>
> https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/4/testReport/org.apache.hadoop.hbase.regionserver.wal/TestAsyncProtobufLog/
>
> On Wed, Dec 9, 2020 at 4:31 PM 张铎(Duo Zhang) 
> wrote:
>
> > OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> > implementation for 9.3 and 9.4 are completely different, there is no
> > problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only
> pass
> > version with two dots, i.e, 11.0.9.
> >
> > I think you could add -Dhadoop-three.version to set the hadoop 3 version
> > explicitly to a newer version which uses jetty 9.4 to solve the problem,
> > IIRC all the newest release for each active release line has upgrade to
> > jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
> > incompatible.
> >
> > Thanks.
> >
> > 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
> >
> > > On nightly jdk11 build the jdk version is
> > >
> > > AdoptOpenJDK-11.0.6+10
> > >
> > > Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> > >
> > >> Let me rephrase.
> > >>
> > >> I'm all for testing the optional configurations. I'm less supportive
> of
> > >> vetoing releases when an optional configuration has some issue due to
> a
> > >> third party component. I would like to see us veto only on the
> required
> > >> configurations, and otherwise file JIRAs to fix up the nits on the
> > >> optional
> > >> ones.
> > >>
> > >>
> > >> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
> > >> wrote:
> > >>
> > >> > > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> > >> >
> > >> > So unless I am mistaken, some Jetty utility class is not able to
> parse
> > >> the
> > >> > version string of your particular JDK/JRE.
> > >> >
> > >> > We can try to downgrade Jetty but I am not sure in general how we
> are
> > >> > supposed to take on the risk of third party dependencies doing the
> > wrong
> > >> > thing in an optional configuration. I for one do not want to deal
> > with a
> > >> > combinatorial explosion of transitive dependencies when releasing.
> > >> >
> > >> >
> > >> > On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
> > >> wrote:
> > >> >
> > >> >> This is coming out of Jetty + Hadoop. This build has a regression
> in
> > >> our
> > >> >> JDK11 support. Or perhaps there's a regression in the upstream
> Hadoop
> > >> >> against which JDK11 builds.
> > >> >>
> > >> >> I'm afraid I must vote -1 until we can sort out the issue. I'd
> > >> appreciate
> > >> >> it if someone else can attempt to repro, help ensure it's not just
> > me.
> > >> >>
> > >> >> Thanks,
> > >> >> Nick
> > >> >>
> > >> >> (Apologies for the crude stack trace; this is copied out of an
> > attached
> > >> >> debugger)
> > >> >>
> > >> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> > >> >> parse:49, JavaVersion (org.eclipse.jetty.util)
> > >> >> :43, JavaVersion (org.eclipse.jetty.util)
> > >> >> findAndFilterContainerPaths:185, WebInfConfiguration
> > >> >> (org.eclipse.jetty.webapp)
> > >> >> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> > >> >> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> > >> >> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> > >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > >> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > >> >> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > >> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> > >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > >> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > >> >> start:427, Server (org.eclipse.jetty.server)
> > >> >> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > >> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> > >> >> doStart:394, Server (org.eclipse.jetty.server)
> > >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > >> >> start:1140, HttpServer2 (org.apache.hadoop.http)
> > >> >> start:177, NameNodeHttpServer
> > (org.apache.hadoop.hdfs.server.namenode)
> > >> >> startHttpServer:872, NameNode
> > (org.apache.hadoop.hdfs.server.namenode)
> > >> >> initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
> > >> >> :940, NameNode (org.apache.hadoop.hdfs.server.namenode)

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

On Wed, Dec 9, 2020 at 5:23 PM Andrew Purtell 
wrote:

> ICYMI, the nightly build passes because the JDK version there has three
> components “11.0.6” and yours fails because your JDK version has four
> components (“11.0.9.1”).
>

Thanks, I did miss this (and I had to look up ICYMI).

As this is a release vote you do not need to withdraw the veto, it does not
> block, but I would ask that you fix your local environment to conform the
> the limitations of Jetty as transitively pulled in via that optional
> profile and retest. This is not an HBase issue and it should not be
> relevant in voting. (IMHO)
>

Since this is indeed a jetty issue, I agree that this is not an HBase issue
and I rescind the -1. Let me grab a slightly different JDK11 build and
resume my evaluation.

> On Dec 9, 2020, at 5:10 PM, Andrew Purtell 
> wrote:
> >
> > Nick,
> >
> > Given the nature of this issue I’d ask you to try Duo’s suggestion and
> if an earlier version of Hadoop 3 succeeds that this be sufficient this
> time around.
> >
> > All,
> >
> > I will start a DISCUSS thread as follow up as to what should be
> considered required and veto worthy for a RC and what should not, with
> regard to optional build profiles. In my opinion ‘required‘ should be
> defined as what is enabled by default in the release build, and ‘optional’
> is everything else until we agree to specifically include one or more
> optional build profiles to the required list.
> >
> >
> >> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
> >>
> >> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> >> implementation for 9.3 and 9.4 are completely different, there is no
> >> problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only
> pass
> >> version with two dots, i.e, 11.0.9.
> >>
> >> I think you could add -Dhadoop-three.version to set the hadoop 3 version
> >> explicitly to a newer version which uses jetty 9.4 to solve the problem,
> >> IIRC all the newest release for each active release line has upgrade to
> >> jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
> >> incompatible.
> >>
> >> Thanks.
> >>
> >> 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
> >>
> >>> On nightly jdk11 build the jdk version is
> >>>
> >>> AdoptOpenJDK-11.0.6+10
> >>>
> >>> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> >>>
>  Let me rephrase.
> 
>  I'm all for testing the optional configurations. I'm less supportive
> of
>  vetoing releases when an optional configuration has some issue due to
> a
>  third party component. I would like to see us veto only on the
> required
>  configurations, and otherwise file JIRAs to fix up the nits on the
>  optional
>  ones.
> 
> 
>  On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
>  wrote:
> 
> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> >
> > So unless I am mistaken, some Jetty utility class is not able to
> parse
>  the
> > version string of your particular JDK/JRE.
> >
> > We can try to downgrade Jetty but I am not sure in general how we are
> > supposed to take on the risk of third party dependencies doing the
> wrong
> > thing in an optional configuration. I for one do not want to deal
> with a
> > combinatorial explosion of transitive dependencies when releasing.
> >
> >
> > On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
>  wrote:
> >
> >> This is coming out of Jetty + Hadoop. This build has a regression in
>  our
> >> JDK11 support. Or perhaps there's a regression in the upstream
> Hadoop
> >> against which JDK11 builds.
> >>
> >> I'm afraid I must vote -1 until we can sort out the issue. I'd
>  appreciate
> >> it if someone else can attempt to repro, help ensure it's not just
> me.
> >>
> >> Thanks,
> >> Nick
> >>
> >> (Apologies for the crude stack trace; this is copied out of an
> attached
> >> debugger)
> >>
> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> >> parse:49, JavaVersion (org.eclipse.jetty.util)
> >> :43, JavaVersion (org.eclipse.jetty.util)
> >> findAndFilterContainerPaths:185, WebInfConfiguration
> >> (org.eclipse.jetty.webapp)
> >> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> >> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> >> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> start:427, Server (org.eclipse.jetty.server)
> >> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.compone

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

So does the RM documentation need update to tell the RM that all supported 
configurations should be tested? Should the release script run through them? 

This is new to me because I’ve been on branch-1 forever so it’s like newbie 
feedback. :-) Java 11 and Hadoop 3 stuff being a potential blocker is 
surprising. I missed the earlier discussion. 


> On Dec 9, 2020, at 5:22 PM, Nick Dimiduk  wrote:
> 
> On Wed, Dec 9, 2020 at 5:11 PM Andrew Purtell 
> wrote:
> 
>> Given the nature of this issue I’d ask you to try Duo’s suggestion and if
>> an earlier version of Hadoop 3 succeeds that this be sufficient this time
>> around.
>> 
> 
> The only version of Hadoop3 we've supported for JDK11 is Hadoop3.2. Hadoop3
> version specified in the pom has not changed since 2.3.0. I can try the
> local build against the newer Hadoop 3.3.0, but that doesn't change this
> being a regression.
> 
> It also occurs to me that perhaps classpath order is at play here, and
> there are different versions of maven in different environments. I haven't
> investigated this yet.
> 
> All,
>> 
>> I will start a DISCUSS thread as follow up as to what should be considered
>> required and veto worthy for a RC and what should not, with regard to
>> optional build profiles. In my opinion ‘required‘ should be defined as what
>> is enabled by default in the release build, and ‘optional’ is everything
>> else until we agree to specifically include one or more optional build
>> profiles to the required list.
>> 
> 
> To the best of my knowledge, JDK11 is not an optional release profile.
> Preliminary support for JDK11 was introduced in 2.3 as a supported
> configuration, and both our book and our build infrastructure were extended
> accordingly. My understanding is that this discussion was settled in the
> lead up to 2.3.0.
> 
> https://hbase.apache.org/book.html#java
> https://hbase.apache.org/book.html#hadoop
> 
>>> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
>>> 
>>> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
>>> implementation for 9.3 and 9.4 are completely different, there is no
>>> problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only
>> pass
>>> version with two dots, i.e, 11.0.9.
>>> 
>>> I think you could add -Dhadoop-three.version to set the hadoop 3 version
>>> explicitly to a newer version which uses jetty 9.4 to solve the problem,
>>> IIRC all the newest release for each active release line has upgrade to
>>> jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
>>> incompatible.
>>> 
>>> Thanks.
>>> 
>>> 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
>>> 
 On nightly jdk11 build the jdk version is
 
 AdoptOpenJDK-11.0.6+10
 
 Andrew Purtell  于2020年12月10日周四 上午7:21写道：
 
> Let me rephrase.
> 
> I'm all for testing the optional configurations. I'm less supportive of
> vetoing releases when an optional configuration has some issue due to a
> third party component. I would like to see us veto only on the required
> configurations, and otherwise file JIRAs to fix up the nits on the
> optional
> ones.
> 
> 
> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
> wrote:
> 
>>> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>> 
>> So unless I am mistaken, some Jetty utility class is not able to parse
> the
>> version string of your particular JDK/JRE.
>> 
>> We can try to downgrade Jetty but I am not sure in general how we are
>> supposed to take on the risk of third party dependencies doing the
>> wrong
>> thing in an optional configuration. I for one do not want to deal
>> with a
>> combinatorial explosion of transitive dependencies when releasing.
>> 
>> 
>> On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
> wrote:
>> 
>>> This is coming out of Jetty + Hadoop. This build has a regression in
> our
>>> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
>>> against which JDK11 builds.
>>> 
>>> I'm afraid I must vote -1 until we can sort out the issue. I'd
> appreciate
>>> it if someone else can attempt to repro, help ensure it's not just
>> me.
>>> 
>>> Thanks,
>>> Nick
>>> 
>>> (Apologies for the crude stack trace; this is copied out of an
>> attached
>>> debugger)
>>> 
>>> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>>> parse:49, JavaVersion (org.eclipse.jetty.util)
>>> :43, JavaVersion (org.eclipse.jetty.util)
>>> findAndFilterContainerPaths:185, WebInfConfiguration
>>> (org.eclipse.jetty.webapp)
>>> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
>>> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
>>> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
>>> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>>> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
>>> doStart:113, Conta

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

ICYMI, the nightly build passes because the JDK version there has three 
components “11.0.6” and yours fails because your JDK version has four 
components (“11.0.9.1”). 

As this is a release vote you do not need to withdraw the veto, it does not 
block, but I would ask that you fix your local environment to conform the the 
limitations of Jetty as transitively pulled in via that optional profile and 
retest. This is not an HBase issue and it should not be relevant in voting. 
(IMHO)


> On Dec 9, 2020, at 5:10 PM, Andrew Purtell  wrote:
> 
> Nick,
> 
> Given the nature of this issue I’d ask you to try Duo’s suggestion and if an 
> earlier version of Hadoop 3 succeeds that this be sufficient this time 
> around. 
> 
> All,
> 
> I will start a DISCUSS thread as follow up as to what should be considered 
> required and veto worthy for a RC and what should not, with regard to 
> optional build profiles. In my opinion ‘required‘ should be defined as what 
> is enabled by default in the release build, and ‘optional’ is everything else 
> until we agree to specifically include one or more optional build profiles to 
> the required list. 
> 
> 
>> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
>> 
>> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
>> implementation for 9.3 and 9.4 are completely different, there is no
>> problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only pass
>> version with two dots, i.e, 11.0.9.
>> 
>> I think you could add -Dhadoop-three.version to set the hadoop 3 version
>> explicitly to a newer version which uses jetty 9.4 to solve the problem,
>> IIRC all the newest release for each active release line has upgrade to
>> jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
>> incompatible.
>> 
>> Thanks.
>> 
>> 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
>> 
>>> On nightly jdk11 build the jdk version is
>>> 
>>> AdoptOpenJDK-11.0.6+10
>>> 
>>> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
>>> 
 Let me rephrase.
 
 I'm all for testing the optional configurations. I'm less supportive of
 vetoing releases when an optional configuration has some issue due to a
 third party component. I would like to see us veto only on the required
 configurations, and otherwise file JIRAs to fix up the nits on the
 optional
 ones.
 
 
 On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
 wrote:
 
>> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> 
> So unless I am mistaken, some Jetty utility class is not able to parse
 the
> version string of your particular JDK/JRE.
> 
> We can try to downgrade Jetty but I am not sure in general how we are
> supposed to take on the risk of third party dependencies doing the wrong
> thing in an optional configuration. I for one do not want to deal with a
> combinatorial explosion of transitive dependencies when releasing.
> 
> 
> On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
 wrote:
> 
>> This is coming out of Jetty + Hadoop. This build has a regression in
 our
>> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
>> against which JDK11 builds.
>> 
>> I'm afraid I must vote -1 until we can sort out the issue. I'd
 appreciate
>> it if someone else can attempt to repro, help ensure it's not just me.
>> 
>> Thanks,
>> Nick
>> 
>> (Apologies for the crude stack trace; this is copied out of an attached
>> debugger)
>> 
>> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>> parse:49, JavaVersion (org.eclipse.jetty.util)
>> :43, JavaVersion (org.eclipse.jetty.util)
>> findAndFilterContainerPaths:185, WebInfConfiguration
>> (org.eclipse.jetty.webapp)
>> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
>> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
>> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
>> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
>> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> start:427, Server (org.eclipse.jetty.server)
>> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
>> doStart:394, Server (org.eclipse.jetty.server)
>> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> start:1140, HttpServer2 (org.apache.hadoop.http)
>> start:177, NameNodeHttpServer (org.apache.hadoop.hdfs.server.namenode)
>> startHttpServer:872, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> initialize:694, NameNode (org.apache.hadoop

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

On Wed, Dec 9, 2020 at 5:11 PM Andrew Purtell 
wrote:

> Given the nature of this issue I’d ask you to try Duo’s suggestion and if
> an earlier version of Hadoop 3 succeeds that this be sufficient this time
> around.
>

The only version of Hadoop3 we've supported for JDK11 is Hadoop3.2. Hadoop3
version specified in the pom has not changed since 2.3.0. I can try the
local build against the newer Hadoop 3.3.0, but that doesn't change this
being a regression.

It also occurs to me that perhaps classpath order is at play here, and
there are different versions of maven in different environments. I haven't
investigated this yet.

All,
>
> I will start a DISCUSS thread as follow up as to what should be considered
> required and veto worthy for a RC and what should not, with regard to
> optional build profiles. In my opinion ‘required‘ should be defined as what
> is enabled by default in the release build, and ‘optional’ is everything
> else until we agree to specifically include one or more optional build
> profiles to the required list.
>

To the best of my knowledge, JDK11 is not an optional release profile.
Preliminary support for JDK11 was introduced in 2.3 as a supported
configuration, and both our book and our build infrastructure were extended
accordingly. My understanding is that this discussion was settled in the
lead up to 2.3.0.

https://hbase.apache.org/book.html#java
https://hbase.apache.org/book.html#hadoop

> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
> >
> > OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> > implementation for 9.3 and 9.4 are completely different, there is no
> > problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only
> pass
> > version with two dots, i.e, 11.0.9.
> >
> > I think you could add -Dhadoop-three.version to set the hadoop 3 version
> > explicitly to a newer version which uses jetty 9.4 to solve the problem,
> > IIRC all the newest release for each active release line has upgrade to
> > jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
> > incompatible.
> >
> > Thanks.
> >
> > 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
> >
> >> On nightly jdk11 build the jdk version is
> >>
> >> AdoptOpenJDK-11.0.6+10
> >>
> >> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> >>
> >>> Let me rephrase.
> >>>
> >>> I'm all for testing the optional configurations. I'm less supportive of
> >>> vetoing releases when an optional configuration has some issue due to a
> >>> third party component. I would like to see us veto only on the required
> >>> configurations, and otherwise file JIRAs to fix up the nits on the
> >>> optional
> >>> ones.
> >>>
> >>>
> >>> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
> >>> wrote:
> >>>
> > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> 
>  So unless I am mistaken, some Jetty utility class is not able to parse
> >>> the
>  version string of your particular JDK/JRE.
> 
>  We can try to downgrade Jetty but I am not sure in general how we are
>  supposed to take on the risk of third party dependencies doing the
> wrong
>  thing in an optional configuration. I for one do not want to deal
> with a
>  combinatorial explosion of transitive dependencies when releasing.
> 
> 
>  On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
> >>> wrote:
> 
> > This is coming out of Jetty + Hadoop. This build has a regression in
> >>> our
> > JDK11 support. Or perhaps there's a regression in the upstream Hadoop
> > against which JDK11 builds.
> >
> > I'm afraid I must vote -1 until we can sort out the issue. I'd
> >>> appreciate
> > it if someone else can attempt to repro, help ensure it's not just
> me.
> >
> > Thanks,
> > Nick
> >
> > (Apologies for the crude stack trace; this is copied out of an
> attached
> > debugger)
> >
> > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> > parse:49, JavaVersion (org.eclipse.jetty.util)
> > :43, JavaVersion (org.eclipse.jetty.util)
> > findAndFilterContainerPaths:185, WebInfConfiguration
> > (org.eclipse.jetty.webapp)
> > preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> > preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> > doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> > start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> > start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> > start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > start:427, Server (org.eclipse.jetty.server)
> > doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
> > doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> > doStart:394, Server (org.e

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Nick,

Given the nature of this issue I’d ask you to try Duo’s suggestion and if an 
earlier version of Hadoop 3 succeeds that this be sufficient this time around. 

All,

I will start a DISCUSS thread as follow up as to what should be considered 
required and veto worthy for a RC and what should not, with regard to optional 
build profiles. In my opinion ‘required‘ should be defined as what is enabled 
by default in the release build, and ‘optional’ is everything else until we 
agree to specifically include one or more optional build profiles to the 
required list. 


> On Dec 9, 2020, at 4:31 PM, 张铎  wrote:
> 
> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> implementation for 9.3 and 9.4 are completely different, there is no
> problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only pass
> version with two dots, i.e, 11.0.9.
> 
> I think you could add -Dhadoop-three.version to set the hadoop 3 version
> explicitly to a newer version which uses jetty 9.4 to solve the problem,
> IIRC all the newest release for each active release line has upgrade to
> jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
> incompatible.
> 
> Thanks.
> 
> 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
> 
>> On nightly jdk11 build the jdk version is
>> 
>> AdoptOpenJDK-11.0.6+10
>> 
>> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
>> 
>>> Let me rephrase.
>>> 
>>> I'm all for testing the optional configurations. I'm less supportive of
>>> vetoing releases when an optional configuration has some issue due to a
>>> third party component. I would like to see us veto only on the required
>>> configurations, and otherwise file JIRAs to fix up the nits on the
>>> optional
>>> ones.
>>> 
>>> 
>>> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
>>> wrote:
>>> 
> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
 
 So unless I am mistaken, some Jetty utility class is not able to parse
>>> the
 version string of your particular JDK/JRE.
 
 We can try to downgrade Jetty but I am not sure in general how we are
 supposed to take on the risk of third party dependencies doing the wrong
 thing in an optional configuration. I for one do not want to deal with a
 combinatorial explosion of transitive dependencies when releasing.
 
 
 On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
>>> wrote:
 
> This is coming out of Jetty + Hadoop. This build has a regression in
>>> our
> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
> against which JDK11 builds.
> 
> I'm afraid I must vote -1 until we can sort out the issue. I'd
>>> appreciate
> it if someone else can attempt to repro, help ensure it's not just me.
> 
> Thanks,
> Nick
> 
> (Apologies for the crude stack trace; this is copied out of an attached
> debugger)
> 
> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> parse:49, JavaVersion (org.eclipse.jetty.util)
> :43, JavaVersion (org.eclipse.jetty.util)
> findAndFilterContainerPaths:185, WebInfConfiguration
> (org.eclipse.jetty.webapp)
> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> start:427, Server (org.eclipse.jetty.server)
> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> doStart:394, Server (org.eclipse.jetty.server)
> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> start:1140, HttpServer2 (org.apache.hadoop.http)
> start:177, NameNodeHttpServer (org.apache.hadoop.hdfs.server.namenode)
> startHttpServer:872, NameNode (org.apache.hadoop.hdfs.server.namenode)
> initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
> :940, NameNode (org.apache.hadoop.hdfs.server.namenode)
> :913, NameNode (org.apache.hadoop.hdfs.server.namenode)
> createNameNode:1646, NameNode (org.apache.hadoop.hdfs.server.namenode)
> createNameNode:1314, MiniDFSCluster (org.apache.hadoop.hdfs)
> configureNameService:1083, MiniDFSCluster (org.apache.hadoop.hdfs)
> createNameNodesAndSetConf:958, MiniDFSCluster (org.apache.hadoop.hdfs)
> initMiniDFSCluster:890, MiniDFSCluster (org.apache.hadoop.hdfs)
> :518, MiniDFSCluster (org.apache.hadoop.hdfs)
> build:477, MiniDFSCluster$Builder (org.apache.hadoop.hdfs)
> startMiniDFSCluster:108, AsyncFSTest

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

Rather than have a user rebuild HBase for themselves and specify
hadoop-three.version, why not bump the Hadoop3 version in our POM?

I also don't have an explanation for why the JDK11 + Hadoop3 build succeeds
in Jenkins. The branch-2.4 build isn't downloading a flakey tests list, so
I don't think these tests are being excluded. In fact, Jenkins records a
successful execution of this test on JDK11/Hadoop3.

https://ci-hadoop.apache.org/job/HBase/job/HBase%20Nightly/job/branch-2.4/4/testReport/org.apache.hadoop.hbase.regionserver.wal/TestAsyncProtobufLog/

On Wed, Dec 9, 2020 at 4:31 PM 张铎(Duo Zhang)  wrote:

> OK, I think the problem is a bug in jetty 9.3, the JavaVersion
> implementation for 9.3 and 9.4 are completely different, there is no
> problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only pass
> version with two dots, i.e, 11.0.9.
>
> I think you could add -Dhadoop-three.version to set the hadoop 3 version
> explicitly to a newer version which uses jetty 9.4 to solve the problem,
> IIRC all the newest release for each active release line has upgrade to
> jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
> incompatible.
>
> Thanks.
>
> 张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：
>
> > On nightly jdk11 build the jdk version is
> >
> > AdoptOpenJDK-11.0.6+10
> >
> > Andrew Purtell  于2020年12月10日周四 上午7:21写道：
> >
> >> Let me rephrase.
> >>
> >> I'm all for testing the optional configurations. I'm less supportive of
> >> vetoing releases when an optional configuration has some issue due to a
> >> third party component. I would like to see us veto only on the required
> >> configurations, and otherwise file JIRAs to fix up the nits on the
> >> optional
> >> ones.
> >>
> >>
> >> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
> >> wrote:
> >>
> >> > > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> >> >
> >> > So unless I am mistaken, some Jetty utility class is not able to parse
> >> the
> >> > version string of your particular JDK/JRE.
> >> >
> >> > We can try to downgrade Jetty but I am not sure in general how we are
> >> > supposed to take on the risk of third party dependencies doing the
> wrong
> >> > thing in an optional configuration. I for one do not want to deal
> with a
> >> > combinatorial explosion of transitive dependencies when releasing.
> >> >
> >> >
> >> > On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> >> This is coming out of Jetty + Hadoop. This build has a regression in
> >> our
> >> >> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
> >> >> against which JDK11 builds.
> >> >>
> >> >> I'm afraid I must vote -1 until we can sort out the issue. I'd
> >> appreciate
> >> >> it if someone else can attempt to repro, help ensure it's not just
> me.
> >> >>
> >> >> Thanks,
> >> >> Nick
> >> >>
> >> >> (Apologies for the crude stack trace; this is copied out of an
> attached
> >> >> debugger)
> >> >>
> >> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> >> >> parse:49, JavaVersion (org.eclipse.jetty.util)
> >> >> :43, JavaVersion (org.eclipse.jetty.util)
> >> >> findAndFilterContainerPaths:185, WebInfConfiguration
> >> >> (org.eclipse.jetty.webapp)
> >> >> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> >> >> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> >> >> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> >> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> >> start:427, Server (org.eclipse.jetty.server)
> >> >> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> >> >> doStart:394, Server (org.eclipse.jetty.server)
> >> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> >> start:1140, HttpServer2 (org.apache.hadoop.http)
> >> >> start:177, NameNodeHttpServer
> (org.apache.hadoop.hdfs.server.namenode)
> >> >> startHttpServer:872, NameNode
> (org.apache.hadoop.hdfs.server.namenode)
> >> >> initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> >> :940, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> >> :913, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> >> createNameNode:1646, NameNode
> (org.apache.hadoop.hdfs.server.namenode)
> >> >> createNameNode:1314, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> >> configureNameService:1083, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> >> createNameNodesAndSetConf:958, MiniDFSCluster
> (org.apache.hadoop.hdfs)
> >> >> initMiniDFSCluster:890, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> >> :518, MiniDFSCluster (org

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Duo Zhang]

OK, I think the problem is a bug in jetty 9.3, the JavaVersion
implementation for 9.3 and 9.4 are completely different, there is no
problem to parse 11.0.9.1 for jetty 9.4 but for jetty 9.3, it can only pass
version with two dots, i.e, 11.0.9.

I think you could add -Dhadoop-three.version to set the hadoop 3 version
explicitly to a newer version which uses jetty 9.4 to solve the problem,
IIRC all the newest release for each active release line has upgrade to
jetty 9.4 and that's why we need to shade jetty as jetty 9.3 and 9.4 are
incompatible.

Thanks.

张铎(Duo Zhang)  于2020年12月10日周四 上午8:21写道：

> On nightly jdk11 build the jdk version is
>
> AdoptOpenJDK-11.0.6+10
>
> Andrew Purtell  于2020年12月10日周四 上午7:21写道：
>
>> Let me rephrase.
>>
>> I'm all for testing the optional configurations. I'm less supportive of
>> vetoing releases when an optional configuration has some issue due to a
>> third party component. I would like to see us veto only on the required
>> configurations, and otherwise file JIRAs to fix up the nits on the
>> optional
>> ones.
>>
>>
>> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell 
>> wrote:
>>
>> > > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>> >
>> > So unless I am mistaken, some Jetty utility class is not able to parse
>> the
>> > version string of your particular JDK/JRE.
>> >
>> > We can try to downgrade Jetty but I am not sure in general how we are
>> > supposed to take on the risk of third party dependencies doing the wrong
>> > thing in an optional configuration. I for one do not want to deal with a
>> > combinatorial explosion of transitive dependencies when releasing.
>> >
>> >
>> > On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk 
>> wrote:
>> >
>> >> This is coming out of Jetty + Hadoop. This build has a regression in
>> our
>> >> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
>> >> against which JDK11 builds.
>> >>
>> >> I'm afraid I must vote -1 until we can sort out the issue. I'd
>> appreciate
>> >> it if someone else can attempt to repro, help ensure it's not just me.
>> >>
>> >> Thanks,
>> >> Nick
>> >>
>> >> (Apologies for the crude stack trace; this is copied out of an attached
>> >> debugger)
>> >>
>> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>> >> parse:49, JavaVersion (org.eclipse.jetty.util)
>> >> :43, JavaVersion (org.eclipse.jetty.util)
>> >> findAndFilterContainerPaths:185, WebInfConfiguration
>> >> (org.eclipse.jetty.webapp)
>> >> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
>> >> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
>> >> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
>> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> >> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
>> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> >> start:427, Server (org.eclipse.jetty.server)
>> >> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
>> >> doStart:394, Server (org.eclipse.jetty.server)
>> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> >> start:1140, HttpServer2 (org.apache.hadoop.http)
>> >> start:177, NameNodeHttpServer (org.apache.hadoop.hdfs.server.namenode)
>> >> startHttpServer:872, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> >> initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> >> :940, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> >> :913, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> >> createNameNode:1646, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> >> createNameNode:1314, MiniDFSCluster (org.apache.hadoop.hdfs)
>> >> configureNameService:1083, MiniDFSCluster (org.apache.hadoop.hdfs)
>> >> createNameNodesAndSetConf:958, MiniDFSCluster (org.apache.hadoop.hdfs)
>> >> initMiniDFSCluster:890, MiniDFSCluster (org.apache.hadoop.hdfs)
>> >> :518, MiniDFSCluster (org.apache.hadoop.hdfs)
>> >> build:477, MiniDFSCluster$Builder (org.apache.hadoop.hdfs)
>> >> startMiniDFSCluster:108, AsyncFSTestBase
>> >> (org.apache.hadoop.hbase.io.asyncfs)
>> >> setUp:87, TestFanOutOneBlockAsyncDFSOutput
>> >> (org.apache.hadoop.hbase.io.asyncfs)
>> >> invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
>> >> invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
>> >> invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
>> >> invoke:566, Method (java.lang.reflect)
>> >> runReflectiveCall:59, FrameworkMethod$1 (org.junit.runners.model)
>> >> run:12, ReflectiveCallable (org.junit.internal.runners.model)
>> >> invokeExplosively:56, FrameworkMethod (org.junit.runners.model)
>> >> invokeMethod:33, RunBefores (org.junit.internal.runners.statements)
>> >> evaluate:24, R

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Duo Zhang]

On nightly jdk11 build the jdk version is

AdoptOpenJDK-11.0.6+10

Andrew Purtell  于2020年12月10日周四 上午7:21写道：

> Let me rephrase.
>
> I'm all for testing the optional configurations. I'm less supportive of
> vetoing releases when an optional configuration has some issue due to a
> third party component. I would like to see us veto only on the required
> configurations, and otherwise file JIRAs to fix up the nits on the optional
> ones.
>
>
> On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell  wrote:
>
> > > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> >
> > So unless I am mistaken, some Jetty utility class is not able to parse
> the
> > version string of your particular JDK/JRE.
> >
> > We can try to downgrade Jetty but I am not sure in general how we are
> > supposed to take on the risk of third party dependencies doing the wrong
> > thing in an optional configuration. I for one do not want to deal with a
> > combinatorial explosion of transitive dependencies when releasing.
> >
> >
> > On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk  wrote:
> >
> >> This is coming out of Jetty + Hadoop. This build has a regression in our
> >> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
> >> against which JDK11 builds.
> >>
> >> I'm afraid I must vote -1 until we can sort out the issue. I'd
> appreciate
> >> it if someone else can attempt to repro, help ensure it's not just me.
> >>
> >> Thanks,
> >> Nick
> >>
> >> (Apologies for the crude stack trace; this is copied out of an attached
> >> debugger)
> >>
> >> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> >> parse:49, JavaVersion (org.eclipse.jetty.util)
> >> :43, JavaVersion (org.eclipse.jetty.util)
> >> findAndFilterContainerPaths:185, WebInfConfiguration
> >> (org.eclipse.jetty.webapp)
> >> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> >> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> >> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> start:427, Server (org.eclipse.jetty.server)
> >> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
> >> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> >> doStart:394, Server (org.eclipse.jetty.server)
> >> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> >> start:1140, HttpServer2 (org.apache.hadoop.http)
> >> start:177, NameNodeHttpServer (org.apache.hadoop.hdfs.server.namenode)
> >> startHttpServer:872, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> :940, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> :913, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> createNameNode:1646, NameNode (org.apache.hadoop.hdfs.server.namenode)
> >> createNameNode:1314, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> configureNameService:1083, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> createNameNodesAndSetConf:958, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> initMiniDFSCluster:890, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> :518, MiniDFSCluster (org.apache.hadoop.hdfs)
> >> build:477, MiniDFSCluster$Builder (org.apache.hadoop.hdfs)
> >> startMiniDFSCluster:108, AsyncFSTestBase
> >> (org.apache.hadoop.hbase.io.asyncfs)
> >> setUp:87, TestFanOutOneBlockAsyncDFSOutput
> >> (org.apache.hadoop.hbase.io.asyncfs)
> >> invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
> >> invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
> >> invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
> >> invoke:566, Method (java.lang.reflect)
> >> runReflectiveCall:59, FrameworkMethod$1 (org.junit.runners.model)
> >> run:12, ReflectiveCallable (org.junit.internal.runners.model)
> >> invokeExplosively:56, FrameworkMethod (org.junit.runners.model)
> >> invokeMethod:33, RunBefores (org.junit.internal.runners.statements)
> >> evaluate:24, RunBefores (org.junit.internal.runners.statements)
> >> evaluate:27, RunAfters (org.junit.internal.runners.statements)
> >> evaluate:38, SystemExitRule$1 (org.apache.hadoop.hbase)
> >> call:288, FailOnTimeout$CallableStatement
> >> (org.junit.internal.runners.statements)
> >> call:282, FailOnTimeout$CallableStatement
> >> (org.junit.internal.runners.statements)
> >> run:264, FutureTask (java.util.concurrent)
> >> run:834, Thread (java.lang)
> >>
> >> On Wed, Dec 9, 2020 at 2:08 PM Nick Dimiduk 
> wrote:
> >>
> >> > On Mon, Dec 7, 2020 at 1:51 PM Nick Dimiduk 
> >> wrote:
> >> >
> >> >> Has anyone successfully built/run this RC with JDK11 and Hadoop3
> >> profile?
> >> >> I'm seeing test failures lo

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Let me rephrase.

I'm all for testing the optional configurations. I'm less supportive of
vetoing releases when an optional configuration has some issue due to a
third party component. I would like to see us veto only on the required
configurations, and otherwise file JIRAs to fix up the nits on the optional
ones.


On Wed, Dec 9, 2020 at 3:19 PM Andrew Purtell  wrote:

> > parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>
> So unless I am mistaken, some Jetty utility class is not able to parse the
> version string of your particular JDK/JRE.
>
> We can try to downgrade Jetty but I am not sure in general how we are
> supposed to take on the risk of third party dependencies doing the wrong
> thing in an optional configuration. I for one do not want to deal with a
> combinatorial explosion of transitive dependencies when releasing.
>
>
> On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk  wrote:
>
>> This is coming out of Jetty + Hadoop. This build has a regression in our
>> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
>> against which JDK11 builds.
>>
>> I'm afraid I must vote -1 until we can sort out the issue. I'd appreciate
>> it if someone else can attempt to repro, help ensure it's not just me.
>>
>> Thanks,
>> Nick
>>
>> (Apologies for the crude stack trace; this is copied out of an attached
>> debugger)
>>
>> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
>> parse:49, JavaVersion (org.eclipse.jetty.util)
>> :43, JavaVersion (org.eclipse.jetty.util)
>> findAndFilterContainerPaths:185, WebInfConfiguration
>> (org.eclipse.jetty.webapp)
>> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
>> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
>> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
>> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
>> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> start:427, Server (org.eclipse.jetty.server)
>> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
>> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
>> doStart:394, Server (org.eclipse.jetty.server)
>> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
>> start:1140, HttpServer2 (org.apache.hadoop.http)
>> start:177, NameNodeHttpServer (org.apache.hadoop.hdfs.server.namenode)
>> startHttpServer:872, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> :940, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> :913, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> createNameNode:1646, NameNode (org.apache.hadoop.hdfs.server.namenode)
>> createNameNode:1314, MiniDFSCluster (org.apache.hadoop.hdfs)
>> configureNameService:1083, MiniDFSCluster (org.apache.hadoop.hdfs)
>> createNameNodesAndSetConf:958, MiniDFSCluster (org.apache.hadoop.hdfs)
>> initMiniDFSCluster:890, MiniDFSCluster (org.apache.hadoop.hdfs)
>> :518, MiniDFSCluster (org.apache.hadoop.hdfs)
>> build:477, MiniDFSCluster$Builder (org.apache.hadoop.hdfs)
>> startMiniDFSCluster:108, AsyncFSTestBase
>> (org.apache.hadoop.hbase.io.asyncfs)
>> setUp:87, TestFanOutOneBlockAsyncDFSOutput
>> (org.apache.hadoop.hbase.io.asyncfs)
>> invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
>> invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
>> invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
>> invoke:566, Method (java.lang.reflect)
>> runReflectiveCall:59, FrameworkMethod$1 (org.junit.runners.model)
>> run:12, ReflectiveCallable (org.junit.internal.runners.model)
>> invokeExplosively:56, FrameworkMethod (org.junit.runners.model)
>> invokeMethod:33, RunBefores (org.junit.internal.runners.statements)
>> evaluate:24, RunBefores (org.junit.internal.runners.statements)
>> evaluate:27, RunAfters (org.junit.internal.runners.statements)
>> evaluate:38, SystemExitRule$1 (org.apache.hadoop.hbase)
>> call:288, FailOnTimeout$CallableStatement
>> (org.junit.internal.runners.statements)
>> call:282, FailOnTimeout$CallableStatement
>> (org.junit.internal.runners.statements)
>> run:264, FutureTask (java.util.concurrent)
>> run:834, Thread (java.lang)
>>
>> On Wed, Dec 9, 2020 at 2:08 PM Nick Dimiduk  wrote:
>>
>> > On Mon, Dec 7, 2020 at 1:51 PM Nick Dimiduk 
>> wrote:
>> >
>> >> Has anyone successfully built/run this RC with JDK11 and Hadoop3
>> profile?
>> >> I'm seeing test failures locally in the hbase-asyncfs module.
>> >> Reproducible with:
>> >>
>> >> $
>> >>
>> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
>> >> mvn clean install -Dhadoop.profile=3.0
>> >>
>> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>> >> ...
>> >> [IN

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)

So unless I am mistaken, some Jetty utility class is not able to parse the
version string of your particular JDK/JRE.

We can try to downgrade Jetty but I am not sure in general how we are
supposed to take on the risk of third party dependencies doing the wrong
thing in an optional configuration. I for one do not want to deal with a
combinatorial explosion of transitive dependencies when releasing.


On Wed, Dec 9, 2020 at 2:41 PM Nick Dimiduk  wrote:

> This is coming out of Jetty + Hadoop. This build has a regression in our
> JDK11 support. Or perhaps there's a regression in the upstream Hadoop
> against which JDK11 builds.
>
> I'm afraid I must vote -1 until we can sort out the issue. I'd appreciate
> it if someone else can attempt to repro, help ensure it's not just me.
>
> Thanks,
> Nick
>
> (Apologies for the crude stack trace; this is copied out of an attached
> debugger)
>
> parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
> parse:49, JavaVersion (org.eclipse.jetty.util)
> :43, JavaVersion (org.eclipse.jetty.util)
> findAndFilterContainerPaths:185, WebInfConfiguration
> (org.eclipse.jetty.webapp)
> preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
> preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
> doStart:521, WebAppContext (org.eclipse.jetty.webapp)
> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
> start:427, Server (org.eclipse.jetty.server)
> doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
> doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
> doStart:394, Server (org.eclipse.jetty.server)
> start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
> start:1140, HttpServer2 (org.apache.hadoop.http)
> start:177, NameNodeHttpServer (org.apache.hadoop.hdfs.server.namenode)
> startHttpServer:872, NameNode (org.apache.hadoop.hdfs.server.namenode)
> initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
> :940, NameNode (org.apache.hadoop.hdfs.server.namenode)
> :913, NameNode (org.apache.hadoop.hdfs.server.namenode)
> createNameNode:1646, NameNode (org.apache.hadoop.hdfs.server.namenode)
> createNameNode:1314, MiniDFSCluster (org.apache.hadoop.hdfs)
> configureNameService:1083, MiniDFSCluster (org.apache.hadoop.hdfs)
> createNameNodesAndSetConf:958, MiniDFSCluster (org.apache.hadoop.hdfs)
> initMiniDFSCluster:890, MiniDFSCluster (org.apache.hadoop.hdfs)
> :518, MiniDFSCluster (org.apache.hadoop.hdfs)
> build:477, MiniDFSCluster$Builder (org.apache.hadoop.hdfs)
> startMiniDFSCluster:108, AsyncFSTestBase
> (org.apache.hadoop.hbase.io.asyncfs)
> setUp:87, TestFanOutOneBlockAsyncDFSOutput
> (org.apache.hadoop.hbase.io.asyncfs)
> invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
> invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
> invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
> invoke:566, Method (java.lang.reflect)
> runReflectiveCall:59, FrameworkMethod$1 (org.junit.runners.model)
> run:12, ReflectiveCallable (org.junit.internal.runners.model)
> invokeExplosively:56, FrameworkMethod (org.junit.runners.model)
> invokeMethod:33, RunBefores (org.junit.internal.runners.statements)
> evaluate:24, RunBefores (org.junit.internal.runners.statements)
> evaluate:27, RunAfters (org.junit.internal.runners.statements)
> evaluate:38, SystemExitRule$1 (org.apache.hadoop.hbase)
> call:288, FailOnTimeout$CallableStatement
> (org.junit.internal.runners.statements)
> call:282, FailOnTimeout$CallableStatement
> (org.junit.internal.runners.statements)
> run:264, FutureTask (java.util.concurrent)
> run:834, Thread (java.lang)
>
> On Wed, Dec 9, 2020 at 2:08 PM Nick Dimiduk  wrote:
>
> > On Mon, Dec 7, 2020 at 1:51 PM Nick Dimiduk  wrote:
> >
> >> Has anyone successfully built/run this RC with JDK11 and Hadoop3
> profile?
> >> I'm seeing test failures locally in the hbase-asyncfs module.
> >> Reproducible with:
> >>
> >> $
> >>
> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> >> mvn clean install -Dhadoop.profile=3.0
> >>
> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> >> ...
> >> [INFO] Running
> >> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> >>
> >>
> >> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> >> 1.785 s <<< FAILURE! - in
> >> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> >>
> >> [ERROR]
> >> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> Time
> >> elapsed: 1.775 s  <<< ERROR!
> >>
> >> java.lang.ExceptionInInitializerError
> >>
> >>
> >> at

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

This is coming out of Jetty + Hadoop. This build has a regression in our
JDK11 support. Or perhaps there's a regression in the upstream Hadoop
against which JDK11 builds.

I'm afraid I must vote -1 until we can sort out the issue. I'd appreciate
it if someone else can attempt to repro, help ensure it's not just me.

Thanks,
Nick

(Apologies for the crude stack trace; this is copied out of an attached
debugger)

parseJDK9:71, JavaVersion (org.eclipse.jetty.util)
parse:49, JavaVersion (org.eclipse.jetty.util)
:43, JavaVersion (org.eclipse.jetty.util)
findAndFilterContainerPaths:185, WebInfConfiguration
(org.eclipse.jetty.webapp)
preConfigure:155, WebInfConfiguration (org.eclipse.jetty.webapp)
preConfigure:485, WebAppContext (org.eclipse.jetty.webapp)
doStart:521, WebAppContext (org.eclipse.jetty.webapp)
start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
doStart:113, ContainerLifeCycle (org.eclipse.jetty.util.component)
doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
start:131, ContainerLifeCycle (org.eclipse.jetty.util.component)
start:427, Server (org.eclipse.jetty.server)
doStart:105, ContainerLifeCycle (org.eclipse.jetty.util.component)
doStart:61, AbstractHandler (org.eclipse.jetty.server.handler)
doStart:394, Server (org.eclipse.jetty.server)
start:68, AbstractLifeCycle (org.eclipse.jetty.util.component)
start:1140, HttpServer2 (org.apache.hadoop.http)
start:177, NameNodeHttpServer (org.apache.hadoop.hdfs.server.namenode)
startHttpServer:872, NameNode (org.apache.hadoop.hdfs.server.namenode)
initialize:694, NameNode (org.apache.hadoop.hdfs.server.namenode)
:940, NameNode (org.apache.hadoop.hdfs.server.namenode)
:913, NameNode (org.apache.hadoop.hdfs.server.namenode)
createNameNode:1646, NameNode (org.apache.hadoop.hdfs.server.namenode)
createNameNode:1314, MiniDFSCluster (org.apache.hadoop.hdfs)
configureNameService:1083, MiniDFSCluster (org.apache.hadoop.hdfs)
createNameNodesAndSetConf:958, MiniDFSCluster (org.apache.hadoop.hdfs)
initMiniDFSCluster:890, MiniDFSCluster (org.apache.hadoop.hdfs)
:518, MiniDFSCluster (org.apache.hadoop.hdfs)
build:477, MiniDFSCluster$Builder (org.apache.hadoop.hdfs)
startMiniDFSCluster:108, AsyncFSTestBase
(org.apache.hadoop.hbase.io.asyncfs)
setUp:87, TestFanOutOneBlockAsyncDFSOutput
(org.apache.hadoop.hbase.io.asyncfs)
invoke0:-1, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:62, NativeMethodAccessorImpl (jdk.internal.reflect)
invoke:43, DelegatingMethodAccessorImpl (jdk.internal.reflect)
invoke:566, Method (java.lang.reflect)
runReflectiveCall:59, FrameworkMethod$1 (org.junit.runners.model)
run:12, ReflectiveCallable (org.junit.internal.runners.model)
invokeExplosively:56, FrameworkMethod (org.junit.runners.model)
invokeMethod:33, RunBefores (org.junit.internal.runners.statements)
evaluate:24, RunBefores (org.junit.internal.runners.statements)
evaluate:27, RunAfters (org.junit.internal.runners.statements)
evaluate:38, SystemExitRule$1 (org.apache.hadoop.hbase)
call:288, FailOnTimeout$CallableStatement
(org.junit.internal.runners.statements)
call:282, FailOnTimeout$CallableStatement
(org.junit.internal.runners.statements)
run:264, FutureTask (java.util.concurrent)
run:834, Thread (java.lang)

On Wed, Dec 9, 2020 at 2:08 PM Nick Dimiduk  wrote:

> On Mon, Dec 7, 2020 at 1:51 PM Nick Dimiduk  wrote:
>
>> Has anyone successfully built/run this RC with JDK11 and Hadoop3 profile?
>> I'm seeing test failures locally in the hbase-asyncfs module.
>> Reproducible with:
>>
>> $
>> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
>> mvn clean install -Dhadoop.profile=3.0
>> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>> ...
>> [INFO] Running
>> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>>
>>
>> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
>> 1.785 s <<< FAILURE! - in
>> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>>
>> [ERROR]
>> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput  Time
>> elapsed: 1.775 s  <<< ERROR!
>>
>> java.lang.ExceptionInInitializerError
>>
>>
>> at
>> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
>>
>> Caused by: java.lang.IllegalArgumentException: Invalid Java version
>> 11.0.9.1
>>
>> at
>> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
>>
>
> This failure is not isolated to macOS. I ran this build on an Ubuntu VM
> with the same AdoptOpenJDK 11.0.9.1. Why don't we see this in Jenkins?
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 0.011 s <<< FAILURE! - in
> org.apache.hadoop.hbase.regionserver.wal.TestAsyncProtobufLog
>
> [ERROR] org.apache.hadoop.hbase.region

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

On Mon, Dec 7, 2020 at 1:51 PM Nick Dimiduk  wrote:

> Has anyone successfully built/run this RC with JDK11 and Hadoop3 profile?
> I'm seeing test failures locally in the hbase-asyncfs module.
> Reproducible with:
>
> $
> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> mvn clean install -Dhadoop.profile=3.0
> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> ...
> [INFO] Running
> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 1.785 s <<< FAILURE! - in
> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>
> [ERROR]
> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput  Time
> elapsed: 1.775 s  <<< ERROR!
>
> java.lang.ExceptionInInitializerError
>
>
> at
> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
>
> Caused by: java.lang.IllegalArgumentException: Invalid Java version
> 11.0.9.1
>
> at
> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
>

This failure is not isolated to macOS. I ran this build on an Ubuntu VM
with the same AdoptOpenJDK 11.0.9.1. Why don't we see this in Jenkins?

[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
0.011 s <<< FAILURE! - in
org.apache.hadoop.hbase.regionserver.wal.TestAsyncProtobufLog

[ERROR] org.apache.hadoop.hbase.regionserver.wal.TestAsyncProtobufLog  Time
elapsed: 0.003 s  <<< ERROR!

java.lang.ExceptionInInitializerError

at
org.apache.hadoop.hbase.regionserver.wal.TestAsyncProtobufLog.setUpBeforeClass(TestAsyncProtobufLog.java:56)

Caused by: java.lang.IllegalArgumentException: Invalid Java version
11.0.9.1
at
org.apache.hadoop.hbase.regionserver.wal.TestAsyncProtobufLog.setUpBeforeClass(TestAsyncProtobufLog.java:56)

On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:
>
>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>>
>> The VOTE will remain open for at least 72 hours.
>>
>> [ ] +1 Release this package as Apache hbase 2.4.0
>> [ ] -1 Do not release this package because ...
>>
>> The tag to be voted on is 2.4.0RC1:
>>
>> https://github.com/apache/hbase/tree/2.4.0RC1
>>
>> The release files, including signatures, digests, as well as CHANGES.md
>> and RELEASENOTES.md included in this RC can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>>
>> Customarily Maven artifacts would be available in a staging repository.
>> Unfortunately I was forced to terminate the Maven deploy step after
>> the upload ran for more than four hours and my build equipment
>> needed to be relocated, with loss of network connectivity. This RC has
>> been delayed long enough. A temporary Maven repository is not a
>> requirement for a vote. I will retry Maven deploy tomorrow. I can
>> promise the artifacts for this RC will be staged in Apache Nexus and
>> ready for release well ahead of the earliest possible time this vote
>> can complete.
>>
>> Artifacts were signed with the apurt...@apache.org key which can be found
>> in:
>>
>> https://dist.apache.org/repos/dist/release/hbase/KEYS
>>
>> The API compatibility report for this RC can be found at:
>>
>>
>>
>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>>
>> The changes are mostly added methods, which conform to the compatibility
>> guidelines for a new minor release. There is one change to the public
>> Region interface that alters the return type of a method. This is
>> equivalent to a removal then addition and can be a binary compatibility
>> problem. However to your RM's eye the change looks intentional and is
>> part of an API improvement project, and a compatibility method is not
>> possible here because Java doesn't consider return type when deciding if
>> one method signature duplicates another.
>>
>> To learn more about Apache HBase, please see
>>
>> http://hbase.apache.org/
>>
>> Thanks,
>> Your HBase Release Manager
>>
>

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Stack figured out how to deploy without .asc.asc files. If I do not hear
any objection soon I will run the magic Maven incantation on the 2.4.0RC1
tag one more time to create another staging repository without the .asc.asc
files. We have already done separate builds during this RC to produce the
assemblies and the Nexus staged artifacts. Making another (final) staging
repository will fix the .asc.asc file nit and not materially change
anything else.


On Tue, Dec 8, 2020 at 12:19 PM Stack  wrote:

> On Tue, Dec 8, 2020 at 8:13 AM Stack  wrote:
>
> > On Mon, Dec 7, 2020 at 9:09 AM Andrew Purtell 
> > wrote:
> >
> >> Thank you, that is very helpful. Please look for the .asc.asc file
> >> problem in the resulting staging repo and write back.
> >>
> >>
> > https://repository.apache.org/content/repositories/orgapachehbase-1418
> is
> > the test build. It has the .asc.asc's. Also per Viraj, it is in 2.3.+. I
> > also see it in some of the 2.1.x builds. I agree the .asc.asc are likely
> > harmless but let me poke at the script some...
> >
>
> HBASE-25376
> S
>
>
>
> > S
> >
> > P.S. Our RM build takes too long.
> >
> >
> >
> >> > On Dec 7, 2020, at 8:53 AM, Stack  wrote:
> >> >
> >> > On Sun, Dec 6, 2020 at 8:41 PM Andrew Purtell <
> >> andrew.purt...@gmail.com>
> >> > wrote:
> >> >
> >> >> Now that the Docker release script is working again (thanks Stack) I
> >> can
> >> >> make a test branch and run that to build a fake RC and examine the
> >> >> resulting temporary repository. If there are .asc.asc files again I’m
> >> not
> >> >> sure we learn more (could be normal, or a POM change introduced into
> >> >> branch-2) but if they are absent then the way forward is clear - a
> new
> >> RC
> >> >> for real. I will do this tomorrow.
> >> >>
> >> >>
> >> > I just started a build on a test branch (I want to make sure all is
> >> fixed
> >> > in the RM'ing scripts). Hope that ok.
> >> > S
> >> >
> >> >
> >> >
> >> >
> >> >>
> >>  On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
> >> >>>
> >> >>> If gpg had verified the signatures I probably wouldn't have noticed
> >> >>> them and we have no other staged repos at the moment, so it's hard
> to
> >> >>> say if this is a new problem. None of the published versions contain
> >> >>> such files, but for all we know nexus filters them when promoting
> the
> >> >>> repository.
> >> >>>
> >> >>> I think Nick said a 2.3.z release was near. We could always see what
> >> >>> that staged maven repo looks like?
> >> >>>
> >>  On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell <
> >> andrew.purt...@gmail.com>
> >> >> wrote:
> >> 
> >>  Even a clean build of 'mvn clean install deploy -DskipTests
> >>  -Papache-release' produces a staging repository containing .asc.asc
> >> >> files. I
> >>  am not doing anything different than the build script, our earlier
> >>  make_rc.sh, and documented procedure. Are we sure this has not
> always
> >> >> been
> >>  the case and now we are just noticing?
> >> 
> >>  The new staging repository is
> >> 
> >> 
> >> https://repository.apache.org/content/repositories/orgapachehbase-1417
> >> 
> >>  and consider, for example:
> >> 
> >> 
> >> >>
> >>
> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
> >> 
> >>  hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020
> 6556
> >>  hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC
> 2020
> >> 833
> >>  *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50
> UTC
> >> >> 2020
> >>  833*
> >>  hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC
> 2020
> >> 32
> >>  hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC
> >> 2020 40
> >>  hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC
> 2020
> >> >> 25432
> >>  hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31
> UTC
> >> >> 2020
> >>  833
> >>  *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06
> 21:42:39
> >> >> UTC
> >>  2020 833*
> >>  hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14
> UTC
> >> >> 2020 32
> >>  hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14
> UTC
> >> >> 2020
> >>  40
> >>  hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020
> 14123
> >>  hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020
> >> 833
> >>  *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC
> >> 2020
> >> >> 833*
> >>  hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020
> 32
> >>  hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020
> >> 40
> >>  hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
> >>  hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
> >>  *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020
> >> 833*
> >> >

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Peter Somogyi]

+1 (binding)

* Changes, release notes: ok
* Basic shell commands: ok
* LTT 1M rows: ok
* UI: ok
* Signature: ok
* Checksum : ok
* Rat check (1.8.0_242): ok
  - mvn clean apache-rat:check "-D hadoop.profile=3.0"
* Built from source (1.8.0_242): ok
  - mvn clean install -DskipTests "-D hadoop.profile=3.0"
* Unit tests pass (1.8.0_242): ok
  - mvn package -P runAllTests "-D hadoop.profile=3.0"
-Dsurefire.rerunFailingTestsCount=3


On Fri, Dec 4, 2020 at 1:05 AM Andrew Purtell  wrote:

> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.4.0RC1:
>
> https://github.com/apache/hbase/tree/2.4.0RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
>
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
>
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> The API compatibility report for this RC can be found at:
>
>
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here because Java doesn't consider return type when deciding if
> one method signature duplicates another.
>
> To learn more about Apache HBase, please see
>
> http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Stack]

On Tue, Dec 8, 2020 at 8:13 AM Stack  wrote:

> On Mon, Dec 7, 2020 at 9:09 AM Andrew Purtell 
> wrote:
>
>> Thank you, that is very helpful. Please look for the .asc.asc file
>> problem in the resulting staging repo and write back.
>>
>>
> https://repository.apache.org/content/repositories/orgapachehbase-1418 is
> the test build. It has the .asc.asc's. Also per Viraj, it is in 2.3.+. I
> also see it in some of the 2.1.x builds. I agree the .asc.asc are likely
> harmless but let me poke at the script some...
>

HBASE-25376
S



> S
>
> P.S. Our RM build takes too long.
>
>
>
>> > On Dec 7, 2020, at 8:53 AM, Stack  wrote:
>> >
>> > On Sun, Dec 6, 2020 at 8:41 PM Andrew Purtell <
>> andrew.purt...@gmail.com>
>> > wrote:
>> >
>> >> Now that the Docker release script is working again (thanks Stack) I
>> can
>> >> make a test branch and run that to build a fake RC and examine the
>> >> resulting temporary repository. If there are .asc.asc files again I’m
>> not
>> >> sure we learn more (could be normal, or a POM change introduced into
>> >> branch-2) but if they are absent then the way forward is clear - a new
>> RC
>> >> for real. I will do this tomorrow.
>> >>
>> >>
>> > I just started a build on a test branch (I want to make sure all is
>> fixed
>> > in the RM'ing scripts). Hope that ok.
>> > S
>> >
>> >
>> >
>> >
>> >>
>>  On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
>> >>>
>> >>> If gpg had verified the signatures I probably wouldn't have noticed
>> >>> them and we have no other staged repos at the moment, so it's hard to
>> >>> say if this is a new problem. None of the published versions contain
>> >>> such files, but for all we know nexus filters them when promoting the
>> >>> repository.
>> >>>
>> >>> I think Nick said a 2.3.z release was near. We could always see what
>> >>> that staged maven repo looks like?
>> >>>
>>  On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell <
>> andrew.purt...@gmail.com>
>> >> wrote:
>> 
>>  Even a clean build of 'mvn clean install deploy -DskipTests
>>  -Papache-release' produces a staging repository containing .asc.asc
>> >> files. I
>>  am not doing anything different than the build script, our earlier
>>  make_rc.sh, and documented procedure. Are we sure this has not always
>> >> been
>>  the case and now we are just noticing?
>> 
>>  The new staging repository is
>> 
>> 
>> https://repository.apache.org/content/repositories/orgapachehbase-1417
>> 
>>  and consider, for example:
>> 
>> 
>> >>
>> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
>> 
>>  hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
>>  hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020
>> 833
>>  *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC
>> >> 2020
>>  833*
>>  hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020
>> 32
>>  hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC
>> 2020 40
>>  hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020
>> >> 25432
>>  hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC
>> >> 2020
>>  833
>>  *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39
>> >> UTC
>>  2020 833*
>>  hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC
>> >> 2020 32
>>  hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC
>> >> 2020
>>  40
>>  hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
>>  hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020
>> 833
>>  *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC
>> 2020
>> >> 833*
>>  hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
>>  hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020
>> 40
>>  hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
>>  hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
>>  *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020
>> 833*
>>  hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
>>  hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
>>  hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
>>  hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
>>  *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020
>> 833*
>>  hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
>>  hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
>> 
>>  Nexus does not care about these files and ignores them.
>> 
>> 
>>  On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell <
>> andrew.purt...@gmail.com
>> >>>
>>  wrote:
>> 
>> > I will drop that temporary repository and make a new one

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Sean Busbey]

I'm +1 for moving forward with the RC and staging repo as is.

Given that nexus is happy to ignore these spurious files we can clean this
up later.

On Tue, Dec 8, 2020, 10:13 Stack  wrote:

> On Mon, Dec 7, 2020 at 9:09 AM Andrew Purtell 
> wrote:
>
> > Thank you, that is very helpful. Please look for the .asc.asc file
> problem
> > in the resulting staging repo and write back.
> >
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1418 is
> the test build. It has the .asc.asc's. Also per Viraj, it is in 2.3.+. I
> also see it in some of the 2.1.x builds. I agree the .asc.asc are likely
> harmless but let me poke at the script some...
> S
>
> P.S. Our RM build takes too long.
>
>
>
> > > On Dec 7, 2020, at 8:53 AM, Stack  wrote:
> > >
> > > On Sun, Dec 6, 2020 at 8:41 PM Andrew Purtell <
> andrew.purt...@gmail.com
> > >
> > > wrote:
> > >
> > >> Now that the Docker release script is working again (thanks Stack) I
> can
> > >> make a test branch and run that to build a fake RC and examine the
> > >> resulting temporary repository. If there are .asc.asc files again I’m
> > not
> > >> sure we learn more (could be normal, or a POM change introduced into
> > >> branch-2) but if they are absent then the way forward is clear - a new
> > RC
> > >> for real. I will do this tomorrow.
> > >>
> > >>
> > > I just started a build on a test branch (I want to make sure all is
> fixed
> > > in the RM'ing scripts). Hope that ok.
> > > S
> > >
> > >
> > >
> > >
> > >>
> >  On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
> > >>>
> > >>> If gpg had verified the signatures I probably wouldn't have noticed
> > >>> them and we have no other staged repos at the moment, so it's hard to
> > >>> say if this is a new problem. None of the published versions contain
> > >>> such files, but for all we know nexus filters them when promoting the
> > >>> repository.
> > >>>
> > >>> I think Nick said a 2.3.z release was near. We could always see what
> > >>> that staged maven repo looks like?
> > >>>
> >  On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell <
> > andrew.purt...@gmail.com>
> > >> wrote:
> > 
> >  Even a clean build of 'mvn clean install deploy -DskipTests
> >  -Papache-release' produces a staging repository containing .asc.asc
> > >> files. I
> >  am not doing anything different than the build script, our earlier
> >  make_rc.sh, and documented procedure. Are we sure this has not
> always
> > >> been
> >  the case and now we are just noticing?
> > 
> >  The new staging repository is
> > 
> > 
> > https://repository.apache.org/content/repositories/orgapachehbase-1417
> > 
> >  and consider, for example:
> > 
> > 
> > >>
> >
> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
> > 
> >  hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020
> 6556
> >  hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020
> > 833
> >  *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC
> > >> 2020
> >  833*
> >  hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020
> > 32
> >  hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC
> 2020
> > 40
> >  hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC
> 2020
> > >> 25432
> >  hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC
> > >> 2020
> >  833
> >  *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06
> 21:42:39
> > >> UTC
> >  2020 833*
> >  hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC
> > >> 2020 32
> >  hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14
> UTC
> > >> 2020
> >  40
> >  hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
> >  hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020
> 833
> >  *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC
> > 2020
> > >> 833*
> >  hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020
> 32
> >  hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020
> 40
> >  hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
> >  hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
> >  *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020
> 833*
> >  hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
> >  hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
> >  hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
> >  hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
> >  *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020
> 833*
> >  hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
> >  hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
> > 
> >  Nexus d

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Stack]

On Mon, Dec 7, 2020 at 9:09 AM Andrew Purtell 
wrote:

> Thank you, that is very helpful. Please look for the .asc.asc file problem
> in the resulting staging repo and write back.
>
>
https://repository.apache.org/content/repositories/orgapachehbase-1418 is
the test build. It has the .asc.asc's. Also per Viraj, it is in 2.3.+. I
also see it in some of the 2.1.x builds. I agree the .asc.asc are likely
harmless but let me poke at the script some...
S

P.S. Our RM build takes too long.



> > On Dec 7, 2020, at 8:53 AM, Stack  wrote:
> >
> > On Sun, Dec 6, 2020 at 8:41 PM Andrew Purtell  >
> > wrote:
> >
> >> Now that the Docker release script is working again (thanks Stack) I can
> >> make a test branch and run that to build a fake RC and examine the
> >> resulting temporary repository. If there are .asc.asc files again I’m
> not
> >> sure we learn more (could be normal, or a POM change introduced into
> >> branch-2) but if they are absent then the way forward is clear - a new
> RC
> >> for real. I will do this tomorrow.
> >>
> >>
> > I just started a build on a test branch (I want to make sure all is fixed
> > in the RM'ing scripts). Hope that ok.
> > S
> >
> >
> >
> >
> >>
>  On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
> >>>
> >>> If gpg had verified the signatures I probably wouldn't have noticed
> >>> them and we have no other staged repos at the moment, so it's hard to
> >>> say if this is a new problem. None of the published versions contain
> >>> such files, but for all we know nexus filters them when promoting the
> >>> repository.
> >>>
> >>> I think Nick said a 2.3.z release was near. We could always see what
> >>> that staged maven repo looks like?
> >>>
>  On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell <
> andrew.purt...@gmail.com>
> >> wrote:
> 
>  Even a clean build of 'mvn clean install deploy -DskipTests
>  -Papache-release' produces a staging repository containing .asc.asc
> >> files. I
>  am not doing anything different than the build script, our earlier
>  make_rc.sh, and documented procedure. Are we sure this has not always
> >> been
>  the case and now we are just noticing?
> 
>  The new staging repository is
> 
> 
> https://repository.apache.org/content/repositories/orgapachehbase-1417
> 
>  and consider, for example:
> 
> 
> >>
> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
> 
>  hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
>  hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020
> 833
>  *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC
> >> 2020
>  833*
>  hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020
> 32
>  hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC 2020
> 40
>  hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020
> >> 25432
>  hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC
> >> 2020
>  833
>  *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39
> >> UTC
>  2020 833*
>  hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC
> >> 2020 32
>  hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC
> >> 2020
>  40
>  hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
>  hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020 833
>  *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC
> 2020
> >> 833*
>  hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
>  hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020 40
>  hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
>  hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
>  *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020 833*
>  hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
>  hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
>  hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
>  hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
>  *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020 833*
>  hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
>  hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
> 
>  Nexus does not care about these files and ignores them.
> 
> 
>  On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell <
> andrew.purt...@gmail.com
> >>>
>  wrote:
> 
> > I will drop that temporary repository and make a new one. I believe I
> >> know
> > what happened. I re-ran the Maven deploy goal after it had failed the
> >> one
> > time without a clean step first. Previous signature files in target/
> >> were
> > themselves included in the list of thi

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Zach York]

Seems reasonable to at least have an easy option for running the
permutations even if it's not the default.

On Mon, Dec 7, 2020 at 3:23 PM Andrew Purtell  wrote:

> > The dev-support/hbase-vote.sh has not been updated to match that logic.
>
> Ok, shall we at least do that? Seems like a good idea, although of course
> the voter's resources will be consumed for a longer period of time.
>
>
> On Mon, Dec 7, 2020 at 2:45 PM Nick Dimiduk  wrote:
>
> > On Mon, Dec 7, 2020 at 2:30 PM Andrew Purtell 
> wrote:
> >
> > > Do we have a list of optional build profiles that are required or
> > > recommended for release or release testing? I might have missed it.
> > >
> > > If we do not have one, shall we start one?
> > >
> > > If we should start a list of optional build profiles that the RM and
> > > release testers should ensure are successful, what should be on it?
> > Should
> > > Java 11 and Hadoop 3 be on it?
> > >
> > > I am in favor of starting this practice with this release and this RC.
> > >
> >
> > These permutations are codified on a per-branch basis in our Jenkinsfile.
> > The dev-support/hbase-vote.sh has not been updated to match that logic.
> >
> > Should we break this question out into a DISCUSS thread?
> > >
> >
> > I don't think it's necessary, though I suppose the details are not well
> > socialized.
> >
> > On Mon, Dec 7, 2020 at 1:52 PM Nick Dimiduk  wrote:
> > >
> > > > Has anyone successfully built/run this RC with JDK11 and Hadoop3
> > profile?
> > >
> >
> > Presumably this test does run with JDK11 + Hadoop3, given HBase Nightly /
> > branch-2.4 / #3 [0] was green.
> >
> > [0]:
> >
> >
> https://ci-hadoop.apache.org/blue/organizations/jenkins/HBase%2FHBase%20Nightly/detail/branch-2.4/3/pipeline/102
> >
> > > I'm seeing test failures locally in the hbase-asyncfs module.
> > > > Reproducible with:
> > > >
> > > > $
> > > >
> > > >
> > >
> >
> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> > > > mvn clean install -Dhadoop.profile=3.0
> > > >
> > >
> >
> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > > > ...
> > > > [INFO] Running
> > > > org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > > >
> > > >
> > > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time
> elapsed:
> > > > 1.785 s <<< FAILURE! - in
> > > > org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > > >
> > > > [ERROR] org.apache.hadoop.hbase.io
> > > > .asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > > >  Time elapsed: 1.775 s  <<< ERROR!
> > > >
> > > > java.lang.ExceptionInInitializerError
> > > >
> > > >
> > > > at
> > > > org.apache.hadoop.hbase.io
> > > >
> > >
> >
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
> > > >
> > > > Caused by: java.lang.IllegalArgumentException: Invalid Java version
> > > > 11.0.9.1
> > > >
> > > > at
> > > > org.apache.hadoop.hbase.io
> > > >
> > >
> >
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
> > > >
> > > > On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell 
> > > wrote:
> > > >
> > > > > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> > > > >
> > > > > The VOTE will remain open for at least 72 hours.
> > > > >
> > > > > [ ] +1 Release this package as Apache hbase 2.4.0
> > > > > [ ] -1 Do not release this package because ...
> > > > >
> > > > > The tag to be voted on is 2.4.0RC1:
> > > > >
> > > > > https://github.com/apache/hbase/tree/2.4.0RC1
> > > > >
> > > > > The release files, including signatures, digests, as well as
> > CHANGES.md
> > > > > and RELEASENOTES.md included in this RC can be found at:
> > > > >
> > > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> > > > >
> > > > > Customarily Maven artifacts would be available in a staging
> > repository.
> > > > > Unfortunately I was forced to terminate the Maven deploy step after
> > > > > the upload ran for more than four hours and my build equipment
> > > > > needed to be relocated, with loss of network connectivity. This RC
> > has
> > > > > been delayed long enough. A temporary Maven repository is not a
> > > > > requirement for a vote. I will retry Maven deploy tomorrow. I can
> > > > > promise the artifacts for this RC will be staged in Apache Nexus
> and
> > > > > ready for release well ahead of the earliest possible time this
> vote
> > > > > can complete.
> > > > >
> > > > > Artifacts were signed with the apurt...@apache.org key which can
> be
> > > > found
> > > > > in:
> > > > >
> > > > > https://dist.apache.org/repos/dist/release/hbase/KEYS
> > > > >
> > > > > The API compatibility report for this RC can be found at:
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> > > > >
> > > > > The changes are mostly added methods, which conform to the
> > > compatibility
> > > > 

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

> The dev-support/hbase-vote.sh has not been updated to match that logic.

Ok, shall we at least do that? Seems like a good idea, although of course
the voter's resources will be consumed for a longer period of time.


On Mon, Dec 7, 2020 at 2:45 PM Nick Dimiduk  wrote:

> On Mon, Dec 7, 2020 at 2:30 PM Andrew Purtell  wrote:
>
> > Do we have a list of optional build profiles that are required or
> > recommended for release or release testing? I might have missed it.
> >
> > If we do not have one, shall we start one?
> >
> > If we should start a list of optional build profiles that the RM and
> > release testers should ensure are successful, what should be on it?
> Should
> > Java 11 and Hadoop 3 be on it?
> >
> > I am in favor of starting this practice with this release and this RC.
> >
>
> These permutations are codified on a per-branch basis in our Jenkinsfile.
> The dev-support/hbase-vote.sh has not been updated to match that logic.
>
> Should we break this question out into a DISCUSS thread?
> >
>
> I don't think it's necessary, though I suppose the details are not well
> socialized.
>
> On Mon, Dec 7, 2020 at 1:52 PM Nick Dimiduk  wrote:
> >
> > > Has anyone successfully built/run this RC with JDK11 and Hadoop3
> profile?
> >
>
> Presumably this test does run with JDK11 + Hadoop3, given HBase Nightly /
> branch-2.4 / #3 [0] was green.
>
> [0]:
>
> https://ci-hadoop.apache.org/blue/organizations/jenkins/HBase%2FHBase%20Nightly/detail/branch-2.4/3/pipeline/102
>
> > I'm seeing test failures locally in the hbase-asyncfs module.
> > > Reproducible with:
> > >
> > > $
> > >
> > >
> >
> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> > > mvn clean install -Dhadoop.profile=3.0
> > >
> >
> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > > ...
> > > [INFO] Running
> > > org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > >
> > >
> > > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > > 1.785 s <<< FAILURE! - in
> > > org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > >
> > > [ERROR] org.apache.hadoop.hbase.io
> > > .asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > >  Time elapsed: 1.775 s  <<< ERROR!
> > >
> > > java.lang.ExceptionInInitializerError
> > >
> > >
> > > at
> > > org.apache.hadoop.hbase.io
> > >
> >
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
> > >
> > > Caused by: java.lang.IllegalArgumentException: Invalid Java version
> > > 11.0.9.1
> > >
> > > at
> > > org.apache.hadoop.hbase.io
> > >
> >
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
> > >
> > > On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell 
> > wrote:
> > >
> > > > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> > > >
> > > > The VOTE will remain open for at least 72 hours.
> > > >
> > > > [ ] +1 Release this package as Apache hbase 2.4.0
> > > > [ ] -1 Do not release this package because ...
> > > >
> > > > The tag to be voted on is 2.4.0RC1:
> > > >
> > > > https://github.com/apache/hbase/tree/2.4.0RC1
> > > >
> > > > The release files, including signatures, digests, as well as
> CHANGES.md
> > > > and RELEASENOTES.md included in this RC can be found at:
> > > >
> > > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> > > >
> > > > Customarily Maven artifacts would be available in a staging
> repository.
> > > > Unfortunately I was forced to terminate the Maven deploy step after
> > > > the upload ran for more than four hours and my build equipment
> > > > needed to be relocated, with loss of network connectivity. This RC
> has
> > > > been delayed long enough. A temporary Maven repository is not a
> > > > requirement for a vote. I will retry Maven deploy tomorrow. I can
> > > > promise the artifacts for this RC will be staged in Apache Nexus and
> > > > ready for release well ahead of the earliest possible time this vote
> > > > can complete.
> > > >
> > > > Artifacts were signed with the apurt...@apache.org key which can be
> > > found
> > > > in:
> > > >
> > > > https://dist.apache.org/repos/dist/release/hbase/KEYS
> > > >
> > > > The API compatibility report for this RC can be found at:
> > > >
> > > >
> > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> > > >
> > > > The changes are mostly added methods, which conform to the
> > compatibility
> > > > guidelines for a new minor release. There is one change to the public
> > > > Region interface that alters the return type of a method. This is
> > > > equivalent to a removal then addition and can be a binary
> compatibility
> > > > problem. However to your RM's eye the change looks intentional and is
> > > > part of an API improvement project, and a compatibility method is not
> > > > possible here because Java doesn't consider return type when decid

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

On Mon, Dec 7, 2020 at 2:30 PM Andrew Purtell  wrote:

> Do we have a list of optional build profiles that are required or
> recommended for release or release testing? I might have missed it.
>
> If we do not have one, shall we start one?
>
> If we should start a list of optional build profiles that the RM and
> release testers should ensure are successful, what should be on it? Should
> Java 11 and Hadoop 3 be on it?
>
> I am in favor of starting this practice with this release and this RC.
>

These permutations are codified on a per-branch basis in our Jenkinsfile.
The dev-support/hbase-vote.sh has not been updated to match that logic.

Should we break this question out into a DISCUSS thread?
>

I don't think it's necessary, though I suppose the details are not well
socialized.

On Mon, Dec 7, 2020 at 1:52 PM Nick Dimiduk  wrote:
>
> > Has anyone successfully built/run this RC with JDK11 and Hadoop3 profile?
>

Presumably this test does run with JDK11 + Hadoop3, given HBase Nightly /
branch-2.4 / #3 [0] was green.

[0]:
https://ci-hadoop.apache.org/blue/organizations/jenkins/HBase%2FHBase%20Nightly/detail/branch-2.4/3/pipeline/102

> I'm seeing test failures locally in the hbase-asyncfs module.
> > Reproducible with:
> >
> > $
> >
> >
> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> > mvn clean install -Dhadoop.profile=3.0
> >
> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> > ...
> > [INFO] Running
> > org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> >
> >
> > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> > 1.785 s <<< FAILURE! - in
> > org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> >
> > [ERROR] org.apache.hadoop.hbase.io
> > .asyncfs.TestFanOutOneBlockAsyncDFSOutput
> >  Time elapsed: 1.775 s  <<< ERROR!
> >
> > java.lang.ExceptionInInitializerError
> >
> >
> > at
> > org.apache.hadoop.hbase.io
> >
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
> >
> > Caused by: java.lang.IllegalArgumentException: Invalid Java version
> > 11.0.9.1
> >
> > at
> > org.apache.hadoop.hbase.io
> >
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
> >
> > On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell 
> wrote:
> >
> > > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> > >
> > > The VOTE will remain open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache hbase 2.4.0
> > > [ ] -1 Do not release this package because ...
> > >
> > > The tag to be voted on is 2.4.0RC1:
> > >
> > > https://github.com/apache/hbase/tree/2.4.0RC1
> > >
> > > The release files, including signatures, digests, as well as CHANGES.md
> > > and RELEASENOTES.md included in this RC can be found at:
> > >
> > > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> > >
> > > Customarily Maven artifacts would be available in a staging repository.
> > > Unfortunately I was forced to terminate the Maven deploy step after
> > > the upload ran for more than four hours and my build equipment
> > > needed to be relocated, with loss of network connectivity. This RC has
> > > been delayed long enough. A temporary Maven repository is not a
> > > requirement for a vote. I will retry Maven deploy tomorrow. I can
> > > promise the artifacts for this RC will be staged in Apache Nexus and
> > > ready for release well ahead of the earliest possible time this vote
> > > can complete.
> > >
> > > Artifacts were signed with the apurt...@apache.org key which can be
> > found
> > > in:
> > >
> > > https://dist.apache.org/repos/dist/release/hbase/KEYS
> > >
> > > The API compatibility report for this RC can be found at:
> > >
> > >
> > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> > >
> > > The changes are mostly added methods, which conform to the
> compatibility
> > > guidelines for a new minor release. There is one change to the public
> > > Region interface that alters the return type of a method. This is
> > > equivalent to a removal then addition and can be a binary compatibility
> > > problem. However to your RM's eye the change looks intentional and is
> > > part of an API improvement project, and a compatibility method is not
> > > possible here because Java doesn't consider return type when deciding
> if
> > > one method signature duplicates another.
> > >
> > > To learn more about Apache HBase, please see
> > >
> > > http://hbase.apache.org/
> > >
> > > Thanks,
> > > Your HBase Release Manager
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Do we have a list of optional build profiles that are required or
recommended for release or release testing? I might have missed it.

If we do not have one, shall we start one?

If we should start a list of optional build profiles that the RM and
release testers should ensure are successful, what should be on it? Should
Java 11 and Hadoop 3 be on it?

I am in favor of starting this practice with this release and this RC.

Should we break this question out into a DISCUSS thread?


On Mon, Dec 7, 2020 at 1:52 PM Nick Dimiduk  wrote:

> Has anyone successfully built/run this RC with JDK11 and Hadoop3 profile?
> I'm seeing test failures locally in the hbase-asyncfs module.
> Reproducible with:
>
> $
>
> JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
> mvn clean install -Dhadoop.profile=3.0
> -Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
> ...
> [INFO] Running
> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 1.785 s <<< FAILURE! - in
> org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
>
> [ERROR] org.apache.hadoop.hbase.io
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput
>  Time elapsed: 1.775 s  <<< ERROR!
>
> java.lang.ExceptionInInitializerError
>
>
> at
> org.apache.hadoop.hbase.io
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
>
> Caused by: java.lang.IllegalArgumentException: Invalid Java version
> 11.0.9.1
>
> at
> org.apache.hadoop.hbase.io
> .asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)
>
> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:
>
> > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.4.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.4.0RC1:
> >
> > https://github.com/apache/hbase/tree/2.4.0RC1
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >
> > Customarily Maven artifacts would be available in a staging repository.
> > Unfortunately I was forced to terminate the Maven deploy step after
> > the upload ran for more than four hours and my build equipment
> > needed to be relocated, with loss of network connectivity. This RC has
> > been delayed long enough. A temporary Maven repository is not a
> > requirement for a vote. I will retry Maven deploy tomorrow. I can
> > promise the artifacts for this RC will be staged in Apache Nexus and
> > ready for release well ahead of the earliest possible time this vote
> > can complete.
> >
> > Artifacts were signed with the apurt...@apache.org key which can be
> found
> > in:
> >
> > https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > The API compatibility report for this RC can be found at:
> >
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> >
> > The changes are mostly added methods, which conform to the compatibility
> > guidelines for a new minor release. There is one change to the public
> > Region interface that alters the return type of a method. This is
> > equivalent to a removal then addition and can be a binary compatibility
> > problem. However to your RM's eye the change looks intentional and is
> > part of an API improvement project, and a compatibility method is not
> > possible here because Java doesn't consider return type when deciding if
> > one method signature duplicates another.
> >
> > To learn more about Apache HBase, please see
> >
> > http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>


-- 
Best regards,
Andrew

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

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

Has anyone successfully built/run this RC with JDK11 and Hadoop3 profile?
I'm seeing test failures locally in the hbase-asyncfs module.
Reproducible with:

$
JAVA_HOME=/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
mvn clean install -Dhadoop.profile=3.0
-Dtest=org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
...
[INFO] Running
org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput


[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
1.785 s <<< FAILURE! - in
org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput

[ERROR] org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput
 Time elapsed: 1.775 s  <<< ERROR!

java.lang.ExceptionInInitializerError


at
org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)

Caused by: java.lang.IllegalArgumentException: Invalid Java version
11.0.9.1

at
org.apache.hadoop.hbase.io.asyncfs.TestFanOutOneBlockAsyncDFSOutput.setUp(TestFanOutOneBlockAsyncDFSOutput.java:87)

On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:

> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.4.0RC1:
>
> https://github.com/apache/hbase/tree/2.4.0RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
>
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
>
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> The API compatibility report for this RC can be found at:
>
>
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here because Java doesn't consider return type when deciding if
> one method signature duplicates another.
>
> To learn more about Apache HBase, please see
>
> http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

I don't need to do this. Viraj checked release repos and the .asc.asc files
have been present since 2.3 releases, which were performed with the release
script. (I don't blame the release script, this seems to be some kind of
Maven issue.)


On Sun, Dec 6, 2020 at 8:41 PM Andrew Purtell 
wrote:

> Now that the Docker release script is working again (thanks Stack) I can
> make a test branch and run that to build a fake RC and examine the
> resulting temporary repository. If there are .asc.asc files again I’m not
> sure we learn more (could be normal, or a POM change introduced into
> branch-2) but if they are absent then the way forward is clear - a new RC
> for real. I will do this tomorrow.
>
>
> > On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
> >
> > If gpg had verified the signatures I probably wouldn't have noticed
> > them and we have no other staged repos at the moment, so it's hard to
> > say if this is a new problem. None of the published versions contain
> > such files, but for all we know nexus filters them when promoting the
> > repository.
> >
> > I think Nick said a 2.3.z release was near. We could always see what
> > that staged maven repo looks like?
> >
> >> On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell 
> wrote:
> >>
> >> Even a clean build of 'mvn clean install deploy -DskipTests
> >> -Papache-release' produces a staging repository containing .asc.asc
> files. I
> >> am not doing anything different than the build script, our earlier
> >> make_rc.sh, and documented procedure. Are we sure this has not always
> been
> >> the case and now we are just noticing?
> >>
> >> The new staging repository is
> >>
> >> https://repository.apache.org/content/repositories/orgapachehbase-1417
> >>
> >> and consider, for example:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
> >>
> >> hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
> >> hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020 833
> >> *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC
> 2020
> >> 833*
> >> hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020 32
> >> hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC 2020 40
> >> hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020
> 25432
> >> hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC
> 2020
> >> 833
> >> *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39
> UTC
> >> 2020 833*
> >> hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC
> 2020 32
> >> hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC
> 2020
> >> 40
> >> hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
> >> hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020 833
> >> *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC 2020
> 833*
> >> hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
> >> hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020 40
> >> hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
> >> hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
> >> *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020 833*
> >> hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
> >> hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
> >> hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
> >> hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
> >> *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020 833*
> >> hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
> >> hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
> >>
> >> Nexus does not care about these files and ignores them.
> >>
> >>
> >> On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell  >
> >> wrote:
> >>
> >>> I will drop that temporary repository and make a new one. I believe I
> know
> >>> what happened. I re-ran the Maven deploy goal after it had failed the
> one
> >>> time without a clean step first. Previous signature files in target/
> were
> >>> themselves included in the list of things to sign (apparently). ‘mvn
> clean
> >>> install deploy -Papache-release’ should do it.
> >>>
> >>> Nexus successfully closed the repository, so the verification rules
> >>> passed. Based on what you are saying Sean that shouldn’t have
> happened. If
> >>> I can reproduce this I will follow up with infra.
> >>>
> >>>
>  On Dec 6, 2020, at 12:45 PM, Sean Busbey  wrote:
> 
>  +1 for the artifacts on dist.a.o for 2.4.0 RC1
> 
>  I'd rather we not use the staged nexus repo orgapachehbase-1416
>  because it appears to have some errors. specifically there's a
>  duplicative '.asc.asc' file for each signed artifact that gpg can't
>  verify.
> 
> > On Fri, Dec 4, 2020 at 11:29 AM Andrew Purtel

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Thanks for looking into it. I’m inclined to consider this a Maven bug of some 
kind. 

Fortunately these files are harmless. This issue should not block any RC until 
it is eventually fixed. 

> On Dec 7, 2020, at 9:43 AM, Viraj Jasani  wrote:
> 
> It seems these files (site.xml.asc.asc and pom.asc.asc) are present
> starting 2.3.0 release.
> 
> On 2020/12/07 17:27:51, Viraj Jasani  wrote: 
>>> Viraj, we have not determined there is a staging repository problem yet.
>> Those files could be “normal” and present in previous RCs and nobody
>> noticed.
>> 
>> Yeah I realized my if condition was not appropriate. +1 stays if we
>> conclude to go ahead with current RC i.e if presence of
>> .asc.asc is not considered a trouble.
>> 
>> While we are talking about absence of any other staged repo, I just checked
>> recently released 2.3.3 repo and
>> I see .asc.asc present there:
>> 
>> Repository Path:
>> /org/apache/hbase/hbase/2.3.3/hbase-2.3.3-site.xml.asc.asc
>> Uploaded by:
>> vjasani
>> Size:
>> 833 Bytes
>> Uploaded Date:
>> Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time)
>> Last Modified:
>> Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time)
>> 
>> Repository Path:
>> /org/apache/hbase/hbase/2.3.3/hbase-2.3.3.pom.asc.asc
>> Uploaded by:
>> vjasani
>> Size:
>> 833 Bytes
>> Uploaded Date:
>> Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time)
>> Last Modified:
>> Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time)
>> 
>> I definitely used docker based create-release for 2.3.2 and 2.3.3 and did
>> not perform any manual action.
>> 
>> 
>> On Mon, Dec 7, 2020 at 10:38 PM Andrew Purtell 
>> wrote:
>> 
>>> Viraj, we have not determined there is a staging repository problem yet.
>>> Those files could be “normal” and present in previous RCs and nobody
>>> noticed.
>>> 
>>> 
> On Dec 7, 2020, at 5:59 AM, Viraj Jasani  wrote:
> 
> +1 (if staging repository issue is resolved for RC1)
> 
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_171): ok
> - mvn clean apache-rat:check
> * Built from source (1.8.0_171): ok
> - mvn clean install -DskipTests
> * CRUD: ok
> * Load 10M rows: ok
> * WebUI: ok
> * Unit tests pass (1.8.0_171): failed
> - mvn package -P runAllTests
> 
> 
> [ERROR] Failures:
> [ERROR] org.apache.hadoop.hbase.client.TestAsyncTableRSCrashPublish.test
> [ERROR]   Run 1: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
>>> after [60,000] msec
 [ERROR]   Run 2: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
>>> after [60,000] msec
 [ERROR]   Run 3: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
>>> after [60,000] msec
 [ERROR]   Run 4: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
>>> after [60,000] msec
 
 Failure seems to have some env issue as branch-2 nightly
 looks good for this test.
 
 
> On 2020/12/04 00:04:37, Andrew Purtell  wrote:
> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> 
> The VOTE will remain open for at least 72 hours.
> 
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
> 
> The tag to be voted on is 2.4.0RC1:
> 
>   https://github.com/apache/hbase/tree/2.4.0RC1
> 
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
> 
>   https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> 
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
> 
> Artifacts were signed with the apurt...@apache.org key which can be
>>> found
> in:
> 
>   https://dist.apache.org/repos/dist/release/hbase/KEYS
> 
> The API compatibility report for this RC can be found at:
> 
> 
> 
>>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> 
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Viraj Jasani]

It seems these files (site.xml.asc.asc and pom.asc.asc) are present
starting 2.3.0 release.

On 2020/12/07 17:27:51, Viraj Jasani  wrote: 
> > Viraj, we have not determined there is a staging repository problem yet.
> Those files could be “normal” and present in previous RCs and nobody
> noticed.
> 
> Yeah I realized my if condition was not appropriate. +1 stays if we
> conclude to go ahead with current RC i.e if presence of
> .asc.asc is not considered a trouble.
> 
> While we are talking about absence of any other staged repo, I just checked
> recently released 2.3.3 repo and
> I see .asc.asc present there:
> 
> Repository Path:
> /org/apache/hbase/hbase/2.3.3/hbase-2.3.3-site.xml.asc.asc
> Uploaded by:
> vjasani
> Size:
> 833 Bytes
> Uploaded Date:
> Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time)
> Last Modified:
> Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time)
> 
> Repository Path:
> /org/apache/hbase/hbase/2.3.3/hbase-2.3.3.pom.asc.asc
> Uploaded by:
> vjasani
> Size:
> 833 Bytes
> Uploaded Date:
> Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time)
> Last Modified:
> Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time)
> 
> I definitely used docker based create-release for 2.3.2 and 2.3.3 and did
> not perform any manual action.
> 
> 
> On Mon, Dec 7, 2020 at 10:38 PM Andrew Purtell 
> wrote:
> 
> > Viraj, we have not determined there is a staging repository problem yet.
> > Those files could be “normal” and present in previous RCs and nobody
> > noticed.
> >
> >
> > > On Dec 7, 2020, at 5:59 AM, Viraj Jasani  wrote:
> > >
> > > +1 (if staging repository issue is resolved for RC1)
> > >
> > > * Signature: ok
> > > * Checksum : ok
> > > * Rat check (1.8.0_171): ok
> > > - mvn clean apache-rat:check
> > > * Built from source (1.8.0_171): ok
> > > - mvn clean install -DskipTests
> > > * CRUD: ok
> > > * Load 10M rows: ok
> > > * WebUI: ok
> > > * Unit tests pass (1.8.0_171): failed
> > > - mvn package -P runAllTests
> > >
> > >
> > > [ERROR] Failures:
> > > [ERROR] org.apache.hadoop.hbase.client.TestAsyncTableRSCrashPublish.test
> > > [ERROR]   Run 1: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> > after [60,000] msec
> > > [ERROR]   Run 2: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> > after [60,000] msec
> > > [ERROR]   Run 3: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> > after [60,000] msec
> > > [ERROR]   Run 4: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> > after [60,000] msec
> > >
> > > Failure seems to have some env issue as branch-2 nightly
> > > looks good for this test.
> > >
> > >
> > >> On 2020/12/04 00:04:37, Andrew Purtell  wrote:
> > >> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> > >>
> > >> The VOTE will remain open for at least 72 hours.
> > >>
> > >> [ ] +1 Release this package as Apache hbase 2.4.0
> > >> [ ] -1 Do not release this package because ...
> > >>
> > >> The tag to be voted on is 2.4.0RC1:
> > >>
> > >>https://github.com/apache/hbase/tree/2.4.0RC1
> > >>
> > >> The release files, including signatures, digests, as well as CHANGES.md
> > >> and RELEASENOTES.md included in this RC can be found at:
> > >>
> > >>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> > >>
> > >> Customarily Maven artifacts would be available in a staging repository.
> > >> Unfortunately I was forced to terminate the Maven deploy step after
> > >> the upload ran for more than four hours and my build equipment
> > >> needed to be relocated, with loss of network connectivity. This RC has
> > >> been delayed long enough. A temporary Maven repository is not a
> > >> requirement for a vote. I will retry Maven deploy tomorrow. I can
> > >> promise the artifacts for this RC will be staged in Apache Nexus and
> > >> ready for release well ahead of the earliest possible time this vote
> > >> can complete.
> > >>
> > >> Artifacts were signed with the apurt...@apache.org key which can be
> > found
> > >> in:
> > >>
> > >>https://dist.apache.org/repos/dist/release/hbase/KEYS
> > >>
> > >> The API compatibility report for this RC can be found at:
> > >>
> > >>
> > >>
> > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> > >>
> > >> The changes are mostly added methods, which conform to the compatibility
> > >> guidelines for a new minor release. There is one change to the public
> > >> Region interface that alters the return type of a method. This is
> > >> equivalent to a removal then addition and can be a binary compatibility
> > >> problem. However to your RM's eye the change looks intentional and is
> > >> part of an API improvement project, and a compatibility method is not
> > >> possible here because Java doesn't consider return type when deciding if
> > >> one method signature duplicates another.
> > >>
> > >> To learn more about Apache HBase, please see
> > >>
> > >>http://hbase.apache.org/
> > >>
> > >> Thanks,
> > >> Your HBase Release Manager

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Viraj Jasani]

> Viraj, we have not determined there is a staging repository problem yet.
Those files could be “normal” and present in previous RCs and nobody
noticed.

Yeah I realized my if condition was not appropriate. +1 stays if we
conclude to go ahead with current RC i.e if presence of
.asc.asc is not considered a trouble.

While we are talking about absence of any other staged repo, I just checked
recently released 2.3.3 repo and
I see .asc.asc present there:

Repository Path:
/org/apache/hbase/hbase/2.3.3/hbase-2.3.3-site.xml.asc.asc
Uploaded by:
vjasani
Size:
833 Bytes
Uploaded Date:
Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time)
Last Modified:
Wed Oct 28 2020 14:51:49 GMT+0530 (India Standard Time)

Repository Path:
/org/apache/hbase/hbase/2.3.3/hbase-2.3.3.pom.asc.asc
Uploaded by:
vjasani
Size:
833 Bytes
Uploaded Date:
Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time)
Last Modified:
Wed Oct 28 2020 14:37:37 GMT+0530 (India Standard Time)

I definitely used docker based create-release for 2.3.2 and 2.3.3 and did
not perform any manual action.


On Mon, Dec 7, 2020 at 10:38 PM Andrew Purtell 
wrote:

> Viraj, we have not determined there is a staging repository problem yet.
> Those files could be “normal” and present in previous RCs and nobody
> noticed.
>
>
> > On Dec 7, 2020, at 5:59 AM, Viraj Jasani  wrote:
> >
> > +1 (if staging repository issue is resolved for RC1)
> >
> > * Signature: ok
> > * Checksum : ok
> > * Rat check (1.8.0_171): ok
> > - mvn clean apache-rat:check
> > * Built from source (1.8.0_171): ok
> > - mvn clean install -DskipTests
> > * CRUD: ok
> > * Load 10M rows: ok
> > * WebUI: ok
> > * Unit tests pass (1.8.0_171): failed
> > - mvn package -P runAllTests
> >
> >
> > [ERROR] Failures:
> > [ERROR] org.apache.hadoop.hbase.client.TestAsyncTableRSCrashPublish.test
> > [ERROR]   Run 1: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> after [60,000] msec
> > [ERROR]   Run 2: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> after [60,000] msec
> > [ERROR]   Run 3: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> after [60,000] msec
> > [ERROR]   Run 4: TestAsyncTableRSCrashPublish.test:94 Waiting timed out
> after [60,000] msec
> >
> > Failure seems to have some env issue as branch-2 nightly
> > looks good for this test.
> >
> >
> >> On 2020/12/04 00:04:37, Andrew Purtell  wrote:
> >> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >>
> >> The VOTE will remain open for at least 72 hours.
> >>
> >> [ ] +1 Release this package as Apache hbase 2.4.0
> >> [ ] -1 Do not release this package because ...
> >>
> >> The tag to be voted on is 2.4.0RC1:
> >>
> >>https://github.com/apache/hbase/tree/2.4.0RC1
> >>
> >> The release files, including signatures, digests, as well as CHANGES.md
> >> and RELEASENOTES.md included in this RC can be found at:
> >>
> >>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >>
> >> Customarily Maven artifacts would be available in a staging repository.
> >> Unfortunately I was forced to terminate the Maven deploy step after
> >> the upload ran for more than four hours and my build equipment
> >> needed to be relocated, with loss of network connectivity. This RC has
> >> been delayed long enough. A temporary Maven repository is not a
> >> requirement for a vote. I will retry Maven deploy tomorrow. I can
> >> promise the artifacts for this RC will be staged in Apache Nexus and
> >> ready for release well ahead of the earliest possible time this vote
> >> can complete.
> >>
> >> Artifacts were signed with the apurt...@apache.org key which can be
> found
> >> in:
> >>
> >>https://dist.apache.org/repos/dist/release/hbase/KEYS
> >>
> >> The API compatibility report for this RC can be found at:
> >>
> >>
> >>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> >>
> >> The changes are mostly added methods, which conform to the compatibility
> >> guidelines for a new minor release. There is one change to the public
> >> Region interface that alters the return type of a method. This is
> >> equivalent to a removal then addition and can be a binary compatibility
> >> problem. However to your RM's eye the change looks intentional and is
> >> part of an API improvement project, and a compatibility method is not
> >> possible here because Java doesn't consider return type when deciding if
> >> one method signature duplicates another.
> >>
> >> To learn more about Apache HBase, please see
> >>
> >>http://hbase.apache.org/
> >>
> >> Thanks,
> >> Your HBase Release Manager
> >>
>


-- 
Thanks,
Viraj

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Thank you, that is very helpful. Please look for the .asc.asc file problem in 
the resulting staging repo and write back. 

> On Dec 7, 2020, at 8:53 AM, Stack  wrote:
> 
> On Sun, Dec 6, 2020 at 8:41 PM Andrew Purtell 
> wrote:
> 
>> Now that the Docker release script is working again (thanks Stack) I can
>> make a test branch and run that to build a fake RC and examine the
>> resulting temporary repository. If there are .asc.asc files again I’m not
>> sure we learn more (could be normal, or a POM change introduced into
>> branch-2) but if they are absent then the way forward is clear - a new RC
>> for real. I will do this tomorrow.
>> 
>> 
> I just started a build on a test branch (I want to make sure all is fixed
> in the RM'ing scripts). Hope that ok.
> S
> 
> 
> 
> 
>> 
 On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
>>> 
>>> If gpg had verified the signatures I probably wouldn't have noticed
>>> them and we have no other staged repos at the moment, so it's hard to
>>> say if this is a new problem. None of the published versions contain
>>> such files, but for all we know nexus filters them when promoting the
>>> repository.
>>> 
>>> I think Nick said a 2.3.z release was near. We could always see what
>>> that staged maven repo looks like?
>>> 
 On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell 
>> wrote:
 
 Even a clean build of 'mvn clean install deploy -DskipTests
 -Papache-release' produces a staging repository containing .asc.asc
>> files. I
 am not doing anything different than the build script, our earlier
 make_rc.sh, and documented procedure. Are we sure this has not always
>> been
 the case and now we are just noticing?
 
 The new staging repository is
 
 https://repository.apache.org/content/repositories/orgapachehbase-1417
 
 and consider, for example:
 
 
>> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
 
 hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
 hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020 833
 *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC
>> 2020
 833*
 hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020 32
 hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC 2020 40
 hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020
>> 25432
 hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC
>> 2020
 833
 *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39
>> UTC
 2020 833*
 hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC
>> 2020 32
 hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC
>> 2020
 40
 hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
 hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020 833
 *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC 2020
>> 833*
 hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
 hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020 40
 hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
 hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
 *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020 833*
 hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
 hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
 hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
 hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
 *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020 833*
 hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
 hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
 
 Nexus does not care about these files and ignores them.
 
 
 On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell >> 
 wrote:
 
> I will drop that temporary repository and make a new one. I believe I
>> know
> what happened. I re-ran the Maven deploy goal after it had failed the
>> one
> time without a clean step first. Previous signature files in target/
>> were
> themselves included in the list of things to sign (apparently). ‘mvn
>> clean
> install deploy -Papache-release’ should do it.
> 
> Nexus successfully closed the repository, so the verification rules
> passed. Based on what you are saying Sean that shouldn’t have
>> happened. If
> I can reproduce this I will follow up with infra.
> 
> 
>> On Dec 6, 2020, at 12:45 PM, Sean Busbey  wrote:
>> 
>> +1 for the artifacts on dist.a.o for 2.4.0 RC1
>> 
>> I'd rather we not use the staged nexus repo orgapachehbase-1416
>> because it appears to have some errors. specifically there's a
>> duplicative '.asc.asc' 

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Viraj, we have not determined there is a staging repository problem yet.  Those 
files could be “normal” and present in previous RCs and nobody noticed. 


> On Dec 7, 2020, at 5:59 AM, Viraj Jasani  wrote:
> 
> +1 (if staging repository issue is resolved for RC1)
> 
> * Signature: ok
> * Checksum : ok
> * Rat check (1.8.0_171): ok
> - mvn clean apache-rat:check
> * Built from source (1.8.0_171): ok
> - mvn clean install -DskipTests
> * CRUD: ok
> * Load 10M rows: ok
> * WebUI: ok
> * Unit tests pass (1.8.0_171): failed
> - mvn package -P runAllTests
> 
> 
> [ERROR] Failures:
> [ERROR] org.apache.hadoop.hbase.client.TestAsyncTableRSCrashPublish.test
> [ERROR]   Run 1: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
> [60,000] msec
> [ERROR]   Run 2: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
> [60,000] msec
> [ERROR]   Run 3: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
> [60,000] msec
> [ERROR]   Run 4: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
> [60,000] msec
> 
> Failure seems to have some env issue as branch-2 nightly
> looks good for this test.
> 
> 
>> On 2020/12/04 00:04:37, Andrew Purtell  wrote: 
>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>> 
>> The VOTE will remain open for at least 72 hours.
>> 
>> [ ] +1 Release this package as Apache hbase 2.4.0
>> [ ] -1 Do not release this package because ...
>> 
>> The tag to be voted on is 2.4.0RC1:
>> 
>>https://github.com/apache/hbase/tree/2.4.0RC1
>> 
>> The release files, including signatures, digests, as well as CHANGES.md
>> and RELEASENOTES.md included in this RC can be found at:
>> 
>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>> 
>> Customarily Maven artifacts would be available in a staging repository.
>> Unfortunately I was forced to terminate the Maven deploy step after
>> the upload ran for more than four hours and my build equipment
>> needed to be relocated, with loss of network connectivity. This RC has
>> been delayed long enough. A temporary Maven repository is not a
>> requirement for a vote. I will retry Maven deploy tomorrow. I can
>> promise the artifacts for this RC will be staged in Apache Nexus and
>> ready for release well ahead of the earliest possible time this vote
>> can complete.
>> 
>> Artifacts were signed with the apurt...@apache.org key which can be found
>> in:
>> 
>>https://dist.apache.org/repos/dist/release/hbase/KEYS
>> 
>> The API compatibility report for this RC can be found at:
>> 
>> 
>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>> 
>> The changes are mostly added methods, which conform to the compatibility
>> guidelines for a new minor release. There is one change to the public
>> Region interface that alters the return type of a method. This is
>> equivalent to a removal then addition and can be a binary compatibility
>> problem. However to your RM's eye the change looks intentional and is
>> part of an API improvement project, and a compatibility method is not
>> possible here because Java doesn't consider return type when deciding if
>> one method signature duplicates another.
>> 
>> To learn more about Apache HBase, please see
>> 
>>http://hbase.apache.org/
>> 
>> Thanks,
>> Your HBase Release Manager
>> 

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Stack]

On Sun, Dec 6, 2020 at 8:41 PM Andrew Purtell 
wrote:

> Now that the Docker release script is working again (thanks Stack) I can
> make a test branch and run that to build a fake RC and examine the
> resulting temporary repository. If there are .asc.asc files again I’m not
> sure we learn more (could be normal, or a POM change introduced into
> branch-2) but if they are absent then the way forward is clear - a new RC
> for real. I will do this tomorrow.
>
>
I just started a build on a test branch (I want to make sure all is fixed
in the RM'ing scripts). Hope that ok.
S




>
> > On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
> >
> > If gpg had verified the signatures I probably wouldn't have noticed
> > them and we have no other staged repos at the moment, so it's hard to
> > say if this is a new problem. None of the published versions contain
> > such files, but for all we know nexus filters them when promoting the
> > repository.
> >
> > I think Nick said a 2.3.z release was near. We could always see what
> > that staged maven repo looks like?
> >
> >> On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell 
> wrote:
> >>
> >> Even a clean build of 'mvn clean install deploy -DskipTests
> >> -Papache-release' produces a staging repository containing .asc.asc
> files. I
> >> am not doing anything different than the build script, our earlier
> >> make_rc.sh, and documented procedure. Are we sure this has not always
> been
> >> the case and now we are just noticing?
> >>
> >> The new staging repository is
> >>
> >> https://repository.apache.org/content/repositories/orgapachehbase-1417
> >>
> >> and consider, for example:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
> >>
> >> hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
> >> hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020 833
> >> *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC
> 2020
> >> 833*
> >> hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020 32
> >> hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC 2020 40
> >> hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020
> 25432
> >> hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC
> 2020
> >> 833
> >> *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39
> UTC
> >> 2020 833*
> >> hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC
> 2020 32
> >> hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC
> 2020
> >> 40
> >> hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
> >> hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020 833
> >> *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC 2020
> 833*
> >> hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
> >> hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020 40
> >> hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
> >> hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
> >> *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020 833*
> >> hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
> >> hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
> >> hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
> >> hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
> >> *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020 833*
> >> hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
> >> hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
> >>
> >> Nexus does not care about these files and ignores them.
> >>
> >>
> >> On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell  >
> >> wrote:
> >>
> >>> I will drop that temporary repository and make a new one. I believe I
> know
> >>> what happened. I re-ran the Maven deploy goal after it had failed the
> one
> >>> time without a clean step first. Previous signature files in target/
> were
> >>> themselves included in the list of things to sign (apparently). ‘mvn
> clean
> >>> install deploy -Papache-release’ should do it.
> >>>
> >>> Nexus successfully closed the repository, so the verification rules
> >>> passed. Based on what you are saying Sean that shouldn’t have
> happened. If
> >>> I can reproduce this I will follow up with infra.
> >>>
> >>>
>  On Dec 6, 2020, at 12:45 PM, Sean Busbey  wrote:
> 
>  +1 for the artifacts on dist.a.o for 2.4.0 RC1
> 
>  I'd rather we not use the staged nexus repo orgapachehbase-1416
>  because it appears to have some errors. specifically there's a
>  duplicative '.asc.asc' file for each signed artifact that gpg can't
>  verify.
> 
> > On Fri, Dec 4, 2020 at 11:29 AM Andrew Purtell 
> >>> wrote:
> >
> > The temporary Maven repository is now available at
> >
> >
> >>>
> https://reposi

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Viraj Jasani]

+1 (if staging repository issue is resolved for RC1)

* Signature: ok
* Checksum : ok
* Rat check (1.8.0_171): ok
 - mvn clean apache-rat:check
* Built from source (1.8.0_171): ok
 - mvn clean install -DskipTests
* CRUD: ok
* Load 10M rows: ok
* WebUI: ok
* Unit tests pass (1.8.0_171): failed
 - mvn package -P runAllTests


[ERROR] Failures:
[ERROR] org.apache.hadoop.hbase.client.TestAsyncTableRSCrashPublish.test
[ERROR]   Run 1: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
[60,000] msec
[ERROR]   Run 2: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
[60,000] msec
[ERROR]   Run 3: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
[60,000] msec
[ERROR]   Run 4: TestAsyncTableRSCrashPublish.test:94 Waiting timed out after 
[60,000] msec

Failure seems to have some env issue as branch-2 nightly
looks good for this test.


On 2020/12/04 00:04:37, Andrew Purtell  wrote: 
> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> 
> The VOTE will remain open for at least 72 hours.
> 
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
> 
> The tag to be voted on is 2.4.0RC1:
> 
> https://github.com/apache/hbase/tree/2.4.0RC1
> 
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
> 
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> 
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
> 
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
> 
> https://dist.apache.org/repos/dist/release/hbase/KEYS
> 
> The API compatibility report for this RC can be found at:
> 
> 
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> 
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here because Java doesn't consider return type when deciding if
> one method signature duplicates another.
> 
> To learn more about Apache HBase, please see
> 
> http://hbase.apache.org/
> 
> Thanks,
> Your HBase Release Manager
> 

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Now that the Docker release script is working again (thanks Stack) I can make a 
test branch and run that to build a fake RC and examine the resulting temporary 
repository. If there are .asc.asc files again I’m not sure we learn more (could 
be normal, or a POM change introduced into branch-2) but if they are absent 
then the way forward is clear - a new RC for real. I will do this tomorrow. 


> On Dec 6, 2020, at 8:26 PM, Sean Busbey  wrote:
> 
> If gpg had verified the signatures I probably wouldn't have noticed
> them and we have no other staged repos at the moment, so it's hard to
> say if this is a new problem. None of the published versions contain
> such files, but for all we know nexus filters them when promoting the
> repository.
> 
> I think Nick said a 2.3.z release was near. We could always see what
> that staged maven repo looks like?
> 
>> On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell  
>> wrote:
>> 
>> Even a clean build of 'mvn clean install deploy -DskipTests
>> -Papache-release' produces a staging repository containing .asc.asc files. I
>> am not doing anything different than the build script, our earlier
>> make_rc.sh, and documented procedure. Are we sure this has not always been
>> the case and now we are just noticing?
>> 
>> The new staging repository is
>> 
>> https://repository.apache.org/content/repositories/orgapachehbase-1417
>> 
>> and consider, for example:
>> 
>> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
>> 
>> hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
>> hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020 833
>> *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC 2020
>> 833*
>> hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020 32
>> hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC 2020 40
>> hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020 25432
>> hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC 2020
>> 833
>> *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39 UTC
>> 2020 833*
>> hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC 2020 32
>> hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC 2020
>> 40
>> hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
>> hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020 833
>> *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC 2020 833*
>> hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
>> hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020 40
>> hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
>> hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
>> *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020 833*
>> hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
>> hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
>> hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
>> hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
>> *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020 833*
>> hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
>> hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
>> 
>> Nexus does not care about these files and ignores them.
>> 
>> 
>> On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell 
>> wrote:
>> 
>>> I will drop that temporary repository and make a new one. I believe I know
>>> what happened. I re-ran the Maven deploy goal after it had failed the one
>>> time without a clean step first. Previous signature files in target/ were
>>> themselves included in the list of things to sign (apparently). ‘mvn clean
>>> install deploy -Papache-release’ should do it.
>>> 
>>> Nexus successfully closed the repository, so the verification rules
>>> passed. Based on what you are saying Sean that shouldn’t have happened. If
>>> I can reproduce this I will follow up with infra.
>>> 
>>> 
 On Dec 6, 2020, at 12:45 PM, Sean Busbey  wrote:
 
 +1 for the artifacts on dist.a.o for 2.4.0 RC1
 
 I'd rather we not use the staged nexus repo orgapachehbase-1416
 because it appears to have some errors. specifically there's a
 duplicative '.asc.asc' file for each signed artifact that gpg can't
 verify.
 
> On Fri, Dec 4, 2020 at 11:29 AM Andrew Purtell 
>>> wrote:
> 
> The temporary Maven repository is now available at
> 
> 
>>> https://repository.apache.org/content/repositories/orgapachehbase-1416/
> .
> 
>> On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell 
>>> wrote:
>> 
>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>> 
>> The VOTE will remain open for at least 72 hours.
>> 
>> [ ] +1 Release this package as Apache hbase 2.4.0
>> [ ] -1 Do not rele

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Sean Busbey]

If gpg had verified the signatures I probably wouldn't have noticed
them and we have no other staged repos at the moment, so it's hard to
say if this is a new problem. None of the published versions contain
such files, but for all we know nexus filters them when promoting the
repository.

I think Nick said a 2.3.z release was near. We could always see what
that staged maven repo looks like?

On Sun, Dec 6, 2020 at 6:22 PM Andrew Purtell  wrote:
>
> Even a clean build of 'mvn clean install deploy -DskipTests
> -Papache-release' produces a staging repository containing .asc.asc files. I
> am not doing anything different than the build script, our earlier
> make_rc.sh, and documented procedure. Are we sure this has not always been
> the case and now we are just noticing?
>
> The new staging repository is
>
> https://repository.apache.org/content/repositories/orgapachehbase-1417
>
> and consider, for example:
>
> https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/
>
> hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
> hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020 833
> *hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC 2020
> 833*
> hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020 32
> hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC 2020 40
> hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020 25432
> hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC 2020
> 833
> *hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39 UTC
> 2020 833*
> hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC 2020 32
> hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC 2020
> 40
> hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
> hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020 833
> *hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC 2020 833*
> hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
> hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020 40
> hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
> hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
> *hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020 833*
> hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
> hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
> hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
> hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
> *hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020 833*
> hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
> hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40
>
> Nexus does not care about these files and ignores them.
>
>
> On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell 
> wrote:
>
> > I will drop that temporary repository and make a new one. I believe I know
> > what happened. I re-ran the Maven deploy goal after it had failed the one
> > time without a clean step first. Previous signature files in target/ were
> > themselves included in the list of things to sign (apparently). ‘mvn clean
> > install deploy -Papache-release’ should do it.
> >
> > Nexus successfully closed the repository, so the verification rules
> > passed. Based on what you are saying Sean that shouldn’t have happened. If
> > I can reproduce this I will follow up with infra.
> >
> >
> > > On Dec 6, 2020, at 12:45 PM, Sean Busbey  wrote:
> > >
> > > +1 for the artifacts on dist.a.o for 2.4.0 RC1
> > >
> > > I'd rather we not use the staged nexus repo orgapachehbase-1416
> > > because it appears to have some errors. specifically there's a
> > > duplicative '.asc.asc' file for each signed artifact that gpg can't
> > > verify.
> > >
> > >> On Fri, Dec 4, 2020 at 11:29 AM Andrew Purtell 
> > wrote:
> > >>
> > >> The temporary Maven repository is now available at
> > >>
> > >>
> > https://repository.apache.org/content/repositories/orgapachehbase-1416/
> > >> .
> > >>
> > >>> On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell 
> > wrote:
> > >>>
> > >>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> > >>>
> > >>> The VOTE will remain open for at least 72 hours.
> > >>>
> > >>> [ ] +1 Release this package as Apache hbase 2.4.0
> > >>> [ ] -1 Do not release this package because ...
> > >>>
> > >>> The tag to be voted on is 2.4.0RC1:
> > >>>
> > >>>https://github.com/apache/hbase/tree/2.4.0RC1
> > >>>
> > >>> The release files, including signatures, digests, as well as CHANGES.md
> > >>> and RELEASENOTES.md included in this RC can be found at:
> > >>>
> > >>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> > >>>
> > >>> Customarily Maven artifacts would be available in a staging repository.
> > >>> Unfortunately I was forced to terminate the Maven deploy st

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

Even a clean build of 'mvn clean install deploy -DskipTests
-Papache-release' produces a staging repository containing .asc.asc files. I
am not doing anything different than the build script, our earlier
make_rc.sh, and documented procedure. Are we sure this has not always been
the case and now we are just noticing?

The new staging repository is

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

and consider, for example:

https://repository.apache.org/content/repositories/orgapachehbase-1417/org/apache/hbase/hbase-annotations/2.4.0/

hbase-annotations-2.4.0-sources.jar Sun Dec 06 21:49:47 UTC 2020 6556
hbase-annotations-2.4.0-sources.jar.asc Sun Dec 06 21:55:39 UTC 2020 833
*hbase-annotations-2.4.0-sources.jar.asc.asc Sun Dec 06 21:50:50 UTC 2020
833*
hbase-annotations-2.4.0-sources.jar.md5 Sun Dec 06 21:49:48 UTC 2020 32
hbase-annotations-2.4.0-sources.jar.sha1 Sun Dec 06 21:49:47 UTC 2020 40
hbase-annotations-2.4.0-test-sources.jar Sun Dec 06 21:59:13 UTC 2020 25432
hbase-annotations-2.4.0-test-sources.jar.asc Sun Dec 06 21:55:31 UTC 2020
833
*hbase-annotations-2.4.0-test-sources.jar.asc.asc Sun Dec 06 21:42:39 UTC
2020 833*
hbase-annotations-2.4.0-test-sources.jar.md5 Sun Dec 06 21:59:14 UTC 2020 32
hbase-annotations-2.4.0-test-sources.jar.sha1 Sun Dec 06 21:59:14 UTC 2020
40
hbase-annotations-2.4.0-tests.jar Sun Dec 06 21:42:21 UTC 2020 14123
hbase-annotations-2.4.0-tests.jar.asc Sun Dec 06 21:42:29 UTC 2020 833
*hbase-annotations-2.4.0-tests.jar.asc.asc Sun Dec 06 21:48:31 UTC 2020 833*
hbase-annotations-2.4.0-tests.jar.md5 Sun Dec 06 21:42:22 UTC 2020 32
hbase-annotations-2.4.0-tests.jar.sha1 Sun Dec 06 21:42:21 UTC 2020 40
hbase-annotations-2.4.0.jar Sun Dec 06 21:59:25 UTC 2020 6661
hbase-annotations-2.4.0.jar.asc Sun Dec 06 21:59:09 UTC 2020 833
*hbase-annotations-2.4.0.jar.asc.asc Sun Dec 06 21:47:24 UTC 2020 833*
hbase-annotations-2.4.0.jar.md5 Sun Dec 06 21:59:26 UTC 2020 32
hbase-annotations-2.4.0.jar.sha1 Sun Dec 06 21:59:25 UTC 2020 40
hbase-annotations-2.4.0.pom Sun Dec 06 21:59:26 UTC 2020 2065
hbase-annotations-2.4.0.pom.asc Sun Dec 06 21:58:53 UTC 2020 833
*hbase-annotations-2.4.0.pom.asc.asc Sun Dec 06 21:58:26 UTC 2020 833*
hbase-annotations-2.4.0.pom.md5 Sun Dec 06 21:59:27 UTC 2020 32
hbase-annotations-2.4.0.pom.sha1 Sun Dec 06 21:59:27 UTC 2020 40

Nexus does not care about these files and ignores them.


On Sun, Dec 6, 2020 at 1:12 PM Andrew Purtell 
wrote:

> I will drop that temporary repository and make a new one. I believe I know
> what happened. I re-ran the Maven deploy goal after it had failed the one
> time without a clean step first. Previous signature files in target/ were
> themselves included in the list of things to sign (apparently). ‘mvn clean
> install deploy -Papache-release’ should do it.
>
> Nexus successfully closed the repository, so the verification rules
> passed. Based on what you are saying Sean that shouldn’t have happened. If
> I can reproduce this I will follow up with infra.
>
>
> > On Dec 6, 2020, at 12:45 PM, Sean Busbey  wrote:
> >
> > +1 for the artifacts on dist.a.o for 2.4.0 RC1
> >
> > I'd rather we not use the staged nexus repo orgapachehbase-1416
> > because it appears to have some errors. specifically there's a
> > duplicative '.asc.asc' file for each signed artifact that gpg can't
> > verify.
> >
> >> On Fri, Dec 4, 2020 at 11:29 AM Andrew Purtell 
> wrote:
> >>
> >> The temporary Maven repository is now available at
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachehbase-1416/
> >> .
> >>
> >>> On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell 
> wrote:
> >>>
> >>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >>>
> >>> The VOTE will remain open for at least 72 hours.
> >>>
> >>> [ ] +1 Release this package as Apache hbase 2.4.0
> >>> [ ] -1 Do not release this package because ...
> >>>
> >>> The tag to be voted on is 2.4.0RC1:
> >>>
> >>>https://github.com/apache/hbase/tree/2.4.0RC1
> >>>
> >>> The release files, including signatures, digests, as well as CHANGES.md
> >>> and RELEASENOTES.md included in this RC can be found at:
> >>>
> >>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >>>
> >>> Customarily Maven artifacts would be available in a staging repository.
> >>> Unfortunately I was forced to terminate the Maven deploy step after
> >>> the upload ran for more than four hours and my build equipment
> >>> needed to be relocated, with loss of network connectivity. This RC has
> >>> been delayed long enough. A temporary Maven repository is not a
> >>> requirement for a vote. I will retry Maven deploy tomorrow. I can
> >>> promise the artifacts for this RC will be staged in Apache Nexus and
> >>> ready for release well ahead of the earliest possible time this vote
> >>> can complete.
> >>>
> >>> Artifacts were signed with the apurt...@apache.org key which can be
> found
> >>> in:
> >>>
> >>>https://dist.apache.org/repos/dist/release/hbase/KEYS
> >>>
> 

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

I will drop that temporary repository and make a new one. I believe I know what 
happened. I re-ran the Maven deploy goal after it had failed the one time 
without a clean step first. Previous signature files in target/ were themselves 
included in the list of things to sign (apparently). ‘mvn clean install deploy 
-Papache-release’ should do it. 

Nexus successfully closed the repository, so the verification rules passed. 
Based on what you are saying Sean that shouldn’t have happened. If I can 
reproduce this I will follow up with infra. 


> On Dec 6, 2020, at 12:45 PM, Sean Busbey  wrote:
> 
> +1 for the artifacts on dist.a.o for 2.4.0 RC1
> 
> I'd rather we not use the staged nexus repo orgapachehbase-1416
> because it appears to have some errors. specifically there's a
> duplicative '.asc.asc' file for each signed artifact that gpg can't
> verify.
> 
>> On Fri, Dec 4, 2020 at 11:29 AM Andrew Purtell  wrote:
>> 
>> The temporary Maven repository is now available at
>> 
>>https://repository.apache.org/content/repositories/orgapachehbase-1416/
>> .
>> 
>>> On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell  wrote:
>>> 
>>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>>> 
>>> The VOTE will remain open for at least 72 hours.
>>> 
>>> [ ] +1 Release this package as Apache hbase 2.4.0
>>> [ ] -1 Do not release this package because ...
>>> 
>>> The tag to be voted on is 2.4.0RC1:
>>> 
>>>https://github.com/apache/hbase/tree/2.4.0RC1
>>> 
>>> The release files, including signatures, digests, as well as CHANGES.md
>>> and RELEASENOTES.md included in this RC can be found at:
>>> 
>>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>>> 
>>> Customarily Maven artifacts would be available in a staging repository.
>>> Unfortunately I was forced to terminate the Maven deploy step after
>>> the upload ran for more than four hours and my build equipment
>>> needed to be relocated, with loss of network connectivity. This RC has
>>> been delayed long enough. A temporary Maven repository is not a
>>> requirement for a vote. I will retry Maven deploy tomorrow. I can
>>> promise the artifacts for this RC will be staged in Apache Nexus and
>>> ready for release well ahead of the earliest possible time this vote
>>> can complete.
>>> 
>>> Artifacts were signed with the apurt...@apache.org key which can be found
>>> in:
>>> 
>>>https://dist.apache.org/repos/dist/release/hbase/KEYS
>>> 
>>> The API compatibility report for this RC can be found at:
>>> 
>>> 
>>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>>> 
>>> The changes are mostly added methods, which conform to the compatibility
>>> guidelines for a new minor release. There is one change to the public
>>> Region interface that alters the return type of a method. This is
>>> equivalent to a removal then addition and can be a binary compatibility
>>> problem. However to your RM's eye the change looks intentional and is
>>> part of an API improvement project, and a compatibility method is not
>>> possible here because Java doesn't consider return type when deciding if
>>> one method signature duplicates another.
>>> 
>>> To learn more about Apache HBase, please see
>>> 
>>>http://hbase.apache.org/
>>> 
>>> Thanks,
>>> Your HBase Release Manager
>>> 
>> 
>> 
>> --
>> Best regards,
>> Andrew
>> 
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>   - A23, Crosstalk

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Sean Busbey]

+1 for the artifacts on dist.a.o for 2.4.0 RC1

I'd rather we not use the staged nexus repo orgapachehbase-1416
because it appears to have some errors. specifically there's a
duplicative '.asc.asc' file for each signed artifact that gpg can't
verify.

On Fri, Dec 4, 2020 at 11:29 AM Andrew Purtell  wrote:
>
> The temporary Maven repository is now available at
>
> https://repository.apache.org/content/repositories/orgapachehbase-1416/
> .
>
> On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell  wrote:
>
> > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.4.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.4.0RC1:
> >
> > https://github.com/apache/hbase/tree/2.4.0RC1
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >
> > Customarily Maven artifacts would be available in a staging repository.
> > Unfortunately I was forced to terminate the Maven deploy step after
> > the upload ran for more than four hours and my build equipment
> > needed to be relocated, with loss of network connectivity. This RC has
> > been delayed long enough. A temporary Maven repository is not a
> > requirement for a vote. I will retry Maven deploy tomorrow. I can
> > promise the artifacts for this RC will be staged in Apache Nexus and
> > ready for release well ahead of the earliest possible time this vote
> > can complete.
> >
> > Artifacts were signed with the apurt...@apache.org key which can be found
> > in:
> >
> > https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > The API compatibility report for this RC can be found at:
> >
> >
> > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> >
> > The changes are mostly added methods, which conform to the compatibility
> > guidelines for a new minor release. There is one change to the public
> > Region interface that alters the return type of a method. This is
> > equivalent to a removal then addition and can be a binary compatibility
> > problem. However to your RM's eye the change looks intentional and is
> > part of an API improvement project, and a compatibility method is not
> > possible here because Java doesn't consider return type when deciding if
> > one method signature duplicates another.
> >
> > To learn more about Apache HBase, please see
> >
> > http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Sean Busbey]

Your memory on limitations of the JLS vs JVM is correct Andrew.

We still maintained wire compatibility so if someone has a specific
issue with being able to recompile their client code for 2.4.0 they
could always keep using 2.3.z clients to work with an updated server.

The release note on HBASE-25242 could do with a small adjustment to
note that folks should recompile any application code that called the
impacted method. I'll go do that now; I don't think it's critical for
the RC.



On Fri, Dec 4, 2020 at 11:15 AM Andrew Purtell  wrote:
>
> This is a borderline change so I left it in but expected this discussion. 
> Changing the return type of a method causes a binary incompatibility but not 
> a source incompatibility. Making a compatibility method is difficult in this 
> case because although the return type is considered part of the method 
> signature the Java compiler only looks at parameters when deciding if a 
> method duplicates another. So we can’t have the old method returning void and 
> the new one returning Result in the same interface. The new method returning 
> Result must also define additional parameters or accept a parameter of a 
> different type. (At least, this is what I recall from earlier work, would be 
> great if I’m wrong.) RowMutations is I would expect relatively uncommonly 
> used. Finally, as an API improvement project this is important work. So I 
> come down on the side of considering this an allowable change. That said, if 
> the consensus is that it is not, it should be straightforward to change this 
> method’s return type back to void and spin a new RC.
>
>
> > On Dec 3, 2020, at 11:04 PM, 张铎  wrote:
> >
> > I think for a minor release, we do not expect a drop-in replacement, so
> > changing the return value from void is fine? You do not need to change your
> > code, just need to recompile it.
> >
> > Thanks.
> >
> > Stack  于2020年12月4日周五 下午1:58写道：
> >
> >> +0 for now until my question below gets an answer.
> >>
> >> Signature is good, hash is good. CHANGES and RELEASENOTES look good too.
> >> Built from the src tgz. Artifact looks right when I untar it.
> >> Started it in standalone mode.
> >> UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time
> >> statistics'... nice).
> >> Loaded 10M rows w/ pe. Read them back out again.
> >> I've been running unit tests over the last few days. There are flakies that
> >> I've been trying
> >> to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't see
> >> the last few as
> >> cause to hold up the RC (NIghtlies on branch-2 have been pretty good of
> >> late, see
> >>
> >> https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/
> >> ).
> >>
> >> Here is my question (Tosihrio?):
> >>
> >> Looking at API changes, this change looks problematic for a minor release:
> >>
> >> hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class
> >> package org.apache.hadoop.hbase.client
> >> [−] Table.mutateRow ( RowMutations rm )  *:*  void  1
> >>
> >> org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V
> >>
> >> ChangeEffect
> >> 1 Return value type has been changed from *void* to *Result*. This method
> >> has been removed because the return type is part of the method signature. A
> >> client program may be interrupted by *NoSuchMethodError* exception.
> >>
> >> Done here
> >>
> >> commit 3775464981b473599c6d1bb24a7eea3badf0ed03
> >> Author: Toshihiro Suzuki 
> >> Date:   Fri Nov 27 03:53:19 2020 +0900
> >>
> >>HBASE-25242 Add Increment/Append support to RowMutations (#2711)
> >>
> >>Signed-off-by: Duo Zhang 
> >>Signed-off-by: Andrew Purtell 
> >>
> >> The issue is called out as an incompatible change. I don't see discussion
> >> on why this is ok in the PRs. Was I looking in right place?
> >>
> >> S
> >>
> >>> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:
> >>>
> >>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >>>
> >>> The VOTE will remain open for at least 72 hours.
> >>>
> >>> [ ] +1 Release this package as Apache hbase 2.4.0
> >>> [ ] -1 Do not release this package because ...
> >>>
> >>> The tag to be voted on is 2.4.0RC1:
> >>>
> >>>https://github.com/apache/hbase/tree/2.4.0RC1
> >>>
> >>> The release files, including signatures, digests, as well as CHANGES.md
> >>> and RELEASENOTES.md included in this RC can be found at:
> >>>
> >>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >>>
> >>> Customarily Maven artifacts would be available in a staging repository.
> >>> Unfortunately I was forced to terminate the Maven deploy step after
> >>> the upload ran for more than four hours and my build equipment
> >>> needed to be relocated, with loss of network connectivity. This RC has
> >>> been delayed long enough. A temporary Maven repository is not a
> >>> requirement for a vote. I will retry Maven deploy tomorrow. I can
> >>> promise the artifacts for this RC will be stage

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Toshihiro Suzuki]

Thank you for raising the discussion. 

I thought changing the return type of the mutateRow method from void to Result 
in HBASE-25242
didn’t violate our release policy according to the doc some guys already 
mentioned. And looks 
like that was already agreed.

Thanks,
Toshihiro Suzuki


> On Dec 5, 2020, at 4:19, Nick Dimiduk  wrote:
> 
> From the section "11.1. Aspirational Semantic Versioning" [0], under the
> heading "Client Binary compatibility", we say:
>> If a Client implements an HBase Interface, a recompile MAY be required
> upgrading to a newer minor version (See release notes for warning about
> incompatible changes). All effort will be made to provide a default
> implementation so this case should not arise.
> 
> This RC contains a change to client-facing API, not to an HBase interface.
> However, I think this guidance holds for all means of consuming the client
> API. Thus, my position is that this API change from HBASE-25242 is
> acceptable under our terms of MINOR release compatibility, and that the
> section of the book that I have cited should be updated, from "If a Client
> implements an HBase Interface, ..." to "For any downstream code that
> consumes an HBase IA.Public API, ..."
> 
> Thanks,
> Nick
> 
> [0]: https://hbase.apache.org/book.html#hbase.versioning.post10
> 
> On Fri, Dec 4, 2020 at 9:15 AM Andrew Purtell 
> wrote:
> 
>> This is a borderline change so I left it in but expected this discussion.
>> Changing the return type of a method causes a binary incompatibility but
>> not a source incompatibility. Making a compatibility method is difficult in
>> this case because although the return type is considered part of the method
>> signature the Java compiler only looks at parameters when deciding if a
>> method duplicates another. So we can’t have the old method returning void
>> and the new one returning Result in the same interface. The new method
>> returning Result must also define additional parameters or accept a
>> parameter of a different type. (At least, this is what I recall from
>> earlier work, would be great if I’m wrong.) RowMutations is I would expect
>> relatively uncommonly used. Finally, as an API improvement project this is
>> important work. So I come down on the side of considering this an allowable
>> change. That said, if the consensus is that it is not, it should be
>> straightforward to change this method’s return type back to void and spin a
>> new RC.
>> 
>> 
>>> On Dec 3, 2020, at 11:04 PM, 张铎  wrote:
>>> 
>>> I think for a minor release, we do not expect a drop-in replacement, so
>>> changing the return value from void is fine? You do not need to change
>> your
>>> code, just need to recompile it.
>>> 
>>> Thanks.
>>> 
>>> Stack  于2020年12月4日周五 下午1:58写道：
>>> 
 +0 for now until my question below gets an answer.
 
 Signature is good, hash is good. CHANGES and RELEASENOTES look good too.
 Built from the src tgz. Artifact looks right when I untar it.
 Started it in standalone mode.
 UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time
 statistics'... nice).
 Loaded 10M rows w/ pe. Read them back out again.
 I've been running unit tests over the last few days. There are flakies
>> that
 I've been trying
 to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't
>> see
 the last few as
 cause to hold up the RC (NIghtlies on branch-2 have been pretty good of
 late, see
 
 
>> https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/
 ).
 
 Here is my question (Tosihrio?):
 
 Looking at API changes, this change looks problematic for a minor
>> release:
 
 hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class
 package org.apache.hadoop.hbase.client
 [−] Table.mutateRow ( RowMutations rm )  *:*  void  1
 
 
>> org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V
 
 ChangeEffect
 1 Return value type has been changed from *void* to *Result*. This
>> method
 has been removed because the return type is part of the method
>> signature. A
 client program may be interrupted by *NoSuchMethodError* exception.
 
 Done here
 
 commit 3775464981b473599c6d1bb24a7eea3badf0ed03
 Author: Toshihiro Suzuki 
 Date:   Fri Nov 27 03:53:19 2020 +0900
 
   HBASE-25242 Add Increment/Append support to RowMutations (#2711)
 
   Signed-off-by: Duo Zhang 
   Signed-off-by: Andrew Purtell 
 
 The issue is called out as an incompatible change. I don't see
>> discussion
 on why this is ok in the PRs. Was I looking in right place?
 
 S
 
> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell 
>> wrote:
> 
> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> 
> The VOTE will remain open for at least 72 hours.
> 
> [ ] +1 Release this package as Apache hbase 2.4

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Huaxiang Sun]

+1 (non-binding)

Put 2.4.0 to a 15 node cluster (3 masters, 12 region servers), configured
HBASE-18070 for both server and client.
Server side, there are 1 primary meta region and 3 meta replica regions.
Run itbll with serverKilling chaos monkey and
added 3 billion rows. itbll finished successfully (verified). Found the
following issue

[1] HBASE-25358  meta
replica regions are assigned to the same region server during SCP.

This issue is not a new issue. When SCP runs, it may assign replica regions
to the same region server,
later balancer run will assign regions to different region servers.


./dev-support/hbase-vote.sh --source
https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1 -P runSmallTests


Result:

* Signature: ok

* Checksum : ok

* Rat check (1.8.0_242): ok

 - mvn clean apache-rat:check

* Built from source (1.8.0_242): ok

 - mvn clean install -DskipTests

* Unit tests pass (1.8.0_242): ok

 - mvn package -P runSmallTests

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Nick Dimiduk]

>From the section "11.1. Aspirational Semantic Versioning" [0], under the
heading "Client Binary compatibility", we say:
> If a Client implements an HBase Interface, a recompile MAY be required
upgrading to a newer minor version (See release notes for warning about
incompatible changes). All effort will be made to provide a default
implementation so this case should not arise.

This RC contains a change to client-facing API, not to an HBase interface.
However, I think this guidance holds for all means of consuming the client
API. Thus, my position is that this API change from HBASE-25242 is
acceptable under our terms of MINOR release compatibility, and that the
section of the book that I have cited should be updated, from "If a Client
implements an HBase Interface, ..." to "For any downstream code that
consumes an HBase IA.Public API, ..."

Thanks,
Nick

[0]: https://hbase.apache.org/book.html#hbase.versioning.post10

On Fri, Dec 4, 2020 at 9:15 AM Andrew Purtell 
wrote:

> This is a borderline change so I left it in but expected this discussion.
> Changing the return type of a method causes a binary incompatibility but
> not a source incompatibility. Making a compatibility method is difficult in
> this case because although the return type is considered part of the method
> signature the Java compiler only looks at parameters when deciding if a
> method duplicates another. So we can’t have the old method returning void
> and the new one returning Result in the same interface. The new method
> returning Result must also define additional parameters or accept a
> parameter of a different type. (At least, this is what I recall from
> earlier work, would be great if I’m wrong.) RowMutations is I would expect
> relatively uncommonly used. Finally, as an API improvement project this is
> important work. So I come down on the side of considering this an allowable
> change. That said, if the consensus is that it is not, it should be
> straightforward to change this method’s return type back to void and spin a
> new RC.
>
>
> > On Dec 3, 2020, at 11:04 PM, 张铎  wrote:
> >
> > I think for a minor release, we do not expect a drop-in replacement, so
> > changing the return value from void is fine? You do not need to change
> your
> > code, just need to recompile it.
> >
> > Thanks.
> >
> > Stack  于2020年12月4日周五 下午1:58写道：
> >
> >> +0 for now until my question below gets an answer.
> >>
> >> Signature is good, hash is good. CHANGES and RELEASENOTES look good too.
> >> Built from the src tgz. Artifact looks right when I untar it.
> >> Started it in standalone mode.
> >> UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time
> >> statistics'... nice).
> >> Loaded 10M rows w/ pe. Read them back out again.
> >> I've been running unit tests over the last few days. There are flakies
> that
> >> I've been trying
> >> to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't
> see
> >> the last few as
> >> cause to hold up the RC (NIghtlies on branch-2 have been pretty good of
> >> late, see
> >>
> >>
> https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/
> >> ).
> >>
> >> Here is my question (Tosihrio?):
> >>
> >> Looking at API changes, this change looks problematic for a minor
> release:
> >>
> >> hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class
> >> package org.apache.hadoop.hbase.client
> >> [−] Table.mutateRow ( RowMutations rm )  *:*  void  1
> >>
> >>
> org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V
> >>
> >> ChangeEffect
> >> 1 Return value type has been changed from *void* to *Result*. This
> method
> >> has been removed because the return type is part of the method
> signature. A
> >> client program may be interrupted by *NoSuchMethodError* exception.
> >>
> >> Done here
> >>
> >> commit 3775464981b473599c6d1bb24a7eea3badf0ed03
> >> Author: Toshihiro Suzuki 
> >> Date:   Fri Nov 27 03:53:19 2020 +0900
> >>
> >>HBASE-25242 Add Increment/Append support to RowMutations (#2711)
> >>
> >>Signed-off-by: Duo Zhang 
> >>Signed-off-by: Andrew Purtell 
> >>
> >> The issue is called out as an incompatible change. I don't see
> discussion
> >> on why this is ok in the PRs. Was I looking in right place?
> >>
> >> S
> >>
> >>> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell 
> wrote:
> >>>
> >>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >>>
> >>> The VOTE will remain open for at least 72 hours.
> >>>
> >>> [ ] +1 Release this package as Apache hbase 2.4.0
> >>> [ ] -1 Do not release this package because ...
> >>>
> >>> The tag to be voted on is 2.4.0RC1:
> >>>
> >>>https://github.com/apache/hbase/tree/2.4.0RC1
> >>>
> >>> The release files, including signatures, digests, as well as CHANGES.md
> >>> and RELEASENOTES.md included in this RC can be found at:
> >>>
> >>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >>>
> >>> Customarily Maven artifacts would be av

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Stack]

I went back to our semantic versioning write-up and see in the 'Client
Binary Compatibility' section:

"If a Client implements an HBase Interface, a recompile MAY be required
upgrading to a newer minor version (See release notes for warning about
incompatible changes). All effort will be made to provide a default
implementation so this case should not arise." See
http://hbase.apache.org/book.html#hbase.versioning.post10

This text is more constraining than drop-in replacement -- i.e. client
implements an HBase Interface -- but would allow that minor updates may
require recompiles.

I think it enough.

I change my vote to +1 on RC0.

S


On Fri, Dec 4, 2020 at 9:15 AM Andrew Purtell 
wrote:

> This is a borderline change so I left it in but expected this discussion.
> Changing the return type of a method causes a binary incompatibility but
> not a source incompatibility. Making a compatibility method is difficult in
> this case because although the return type is considered part of the method
> signature the Java compiler only looks at parameters when deciding if a
> method duplicates another. So we can’t have the old method returning void
> and the new one returning Result in the same interface. The new method
> returning Result must also define additional parameters or accept a
> parameter of a different type. (At least, this is what I recall from
> earlier work, would be great if I’m wrong.) RowMutations is I would expect
> relatively uncommonly used. Finally, as an API improvement project this is
> important work. So I come down on the side of considering this an allowable
> change. That said, if the consensus is that it is not, it should be
> straightforward to change this method’s return type back to void and spin a
> new RC.
>
>
> > On Dec 3, 2020, at 11:04 PM, 张铎  wrote:
> >
> > I think for a minor release, we do not expect a drop-in replacement, so
> > changing the return value from void is fine? You do not need to change
> your
> > code, just need to recompile it.
> >
> > Thanks.
> >
> > Stack  于2020年12月4日周五 下午1:58写道：
> >
> >> +0 for now until my question below gets an answer.
> >>
> >> Signature is good, hash is good. CHANGES and RELEASENOTES look good too.
> >> Built from the src tgz. Artifact looks right when I untar it.
> >> Started it in standalone mode.
> >> UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time
> >> statistics'... nice).
> >> Loaded 10M rows w/ pe. Read them back out again.
> >> I've been running unit tests over the last few days. There are flakies
> that
> >> I've been trying
> >> to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't
> see
> >> the last few as
> >> cause to hold up the RC (NIghtlies on branch-2 have been pretty good of
> >> late, see
> >>
> >>
> https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/
> >> ).
> >>
> >> Here is my question (Tosihrio?):
> >>
> >> Looking at API changes, this change looks problematic for a minor
> release:
> >>
> >> hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class
> >> package org.apache.hadoop.hbase.client
> >> [−] Table.mutateRow ( RowMutations rm )  *:*  void  1
> >>
> >>
> org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V
> >>
> >> ChangeEffect
> >> 1 Return value type has been changed from *void* to *Result*. This
> method
> >> has been removed because the return type is part of the method
> signature. A
> >> client program may be interrupted by *NoSuchMethodError* exception.
> >>
> >> Done here
> >>
> >> commit 3775464981b473599c6d1bb24a7eea3badf0ed03
> >> Author: Toshihiro Suzuki 
> >> Date:   Fri Nov 27 03:53:19 2020 +0900
> >>
> >>HBASE-25242 Add Increment/Append support to RowMutations (#2711)
> >>
> >>Signed-off-by: Duo Zhang 
> >>Signed-off-by: Andrew Purtell 
> >>
> >> The issue is called out as an incompatible change. I don't see
> discussion
> >> on why this is ok in the PRs. Was I looking in right place?
> >>
> >> S
> >>
> >>> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell 
> wrote:
> >>>
> >>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >>>
> >>> The VOTE will remain open for at least 72 hours.
> >>>
> >>> [ ] +1 Release this package as Apache hbase 2.4.0
> >>> [ ] -1 Do not release this package because ...
> >>>
> >>> The tag to be voted on is 2.4.0RC1:
> >>>
> >>>https://github.com/apache/hbase/tree/2.4.0RC1
> >>>
> >>> The release files, including signatures, digests, as well as CHANGES.md
> >>> and RELEASENOTES.md included in this RC can be found at:
> >>>
> >>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >>>
> >>> Customarily Maven artifacts would be available in a staging repository.
> >>> Unfortunately I was forced to terminate the Maven deploy step after
> >>> the upload ran for more than four hours and my build equipment
> >>> needed to be relocated, with loss of network connectivity. This RC has
> >>> been delayed long enough. A 

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

The temporary Maven repository is now available at

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

On Thu, Dec 3, 2020 at 4:04 PM Andrew Purtell  wrote:

> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.4.0RC1:
>
> https://github.com/apache/hbase/tree/2.4.0RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
>
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
>
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> The API compatibility report for this RC can be found at:
>
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here because Java doesn't consider return type when deciding if
> one method signature duplicates another.
>
> To learn more about Apache HBase, please see
>
> http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>


-- 
Best regards,
Andrew

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

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Andrew Purtell]

This is a borderline change so I left it in but expected this discussion. 
Changing the return type of a method causes a binary incompatibility but not a 
source incompatibility. Making a compatibility method is difficult in this case 
because although the return type is considered part of the method signature the 
Java compiler only looks at parameters when deciding if a method duplicates 
another. So we can’t have the old method returning void and the new one 
returning Result in the same interface. The new method returning Result must 
also define additional parameters or accept a parameter of a different type. 
(At least, this is what I recall from earlier work, would be great if I’m 
wrong.) RowMutations is I would expect relatively uncommonly used. Finally, as 
an API improvement project this is important work. So I come down on the side 
of considering this an allowable change. That said, if the consensus is that it 
is not, it should be straightforward to change this method’s return type back 
to void and spin a new RC. 


> On Dec 3, 2020, at 11:04 PM, 张铎  wrote:
> 
> I think for a minor release, we do not expect a drop-in replacement, so
> changing the return value from void is fine? You do not need to change your
> code, just need to recompile it.
> 
> Thanks.
> 
> Stack  于2020年12月4日周五 下午1:58写道：
> 
>> +0 for now until my question below gets an answer.
>> 
>> Signature is good, hash is good. CHANGES and RELEASENOTES look good too.
>> Built from the src tgz. Artifact looks right when I untar it.
>> Started it in standalone mode.
>> UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time
>> statistics'... nice).
>> Loaded 10M rows w/ pe. Read them back out again.
>> I've been running unit tests over the last few days. There are flakies that
>> I've been trying
>> to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't see
>> the last few as
>> cause to hold up the RC (NIghtlies on branch-2 have been pretty good of
>> late, see
>> 
>> https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/
>> ).
>> 
>> Here is my question (Tosihrio?):
>> 
>> Looking at API changes, this change looks problematic for a minor release:
>> 
>> hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class
>> package org.apache.hadoop.hbase.client
>> [−] Table.mutateRow ( RowMutations rm )  *:*  void  1
>> 
>> org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V
>> 
>> ChangeEffect
>> 1 Return value type has been changed from *void* to *Result*. This method
>> has been removed because the return type is part of the method signature. A
>> client program may be interrupted by *NoSuchMethodError* exception.
>> 
>> Done here
>> 
>> commit 3775464981b473599c6d1bb24a7eea3badf0ed03
>> Author: Toshihiro Suzuki 
>> Date:   Fri Nov 27 03:53:19 2020 +0900
>> 
>>HBASE-25242 Add Increment/Append support to RowMutations (#2711)
>> 
>>Signed-off-by: Duo Zhang 
>>Signed-off-by: Andrew Purtell 
>> 
>> The issue is called out as an incompatible change. I don't see discussion
>> on why this is ok in the PRs. Was I looking in right place?
>> 
>> S
>> 
>>> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:
>>> 
>>> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>>> 
>>> The VOTE will remain open for at least 72 hours.
>>> 
>>> [ ] +1 Release this package as Apache hbase 2.4.0
>>> [ ] -1 Do not release this package because ...
>>> 
>>> The tag to be voted on is 2.4.0RC1:
>>> 
>>>https://github.com/apache/hbase/tree/2.4.0RC1
>>> 
>>> The release files, including signatures, digests, as well as CHANGES.md
>>> and RELEASENOTES.md included in this RC can be found at:
>>> 
>>>https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>>> 
>>> Customarily Maven artifacts would be available in a staging repository.
>>> Unfortunately I was forced to terminate the Maven deploy step after
>>> the upload ran for more than four hours and my build equipment
>>> needed to be relocated, with loss of network connectivity. This RC has
>>> been delayed long enough. A temporary Maven repository is not a
>>> requirement for a vote. I will retry Maven deploy tomorrow. I can
>>> promise the artifacts for this RC will be staged in Apache Nexus and
>>> ready for release well ahead of the earliest possible time this vote
>>> can complete.
>>> 
>>> Artifacts were signed with the apurt...@apache.org key which can be
>> found
>>> in:
>>> 
>>>https://dist.apache.org/repos/dist/release/hbase/KEYS
>>> 
>>> The API compatibility report for this RC can be found at:
>>> 
>>> 
>>> 
>>> 
>> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>>> 
>>> The changes are mostly added methods, which conform to the compatibility
>>> guidelines for a new minor release. There is one change to the public
>>> Region interface that alters the return type of a method. This is
>>> equivalent to a removal then addition

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Duo Zhang]

I think for a minor release, we do not expect a drop-in replacement, so
changing the return value from void is fine? You do not need to change your
code, just need to recompile it.

Thanks.

Stack  于2020年12月4日周五 下午1:58写道：

> +0 for now until my question below gets an answer.
>
> Signature is good, hash is good. CHANGES and RELEASENOTES look good too.
> Built from the src tgz. Artifact looks right when I untar it.
> Started it in standalone mode.
> UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time
> statistics'... nice).
> Loaded 10M rows w/ pe. Read them back out again.
> I've been running unit tests over the last few days. There are flakies that
> I've been trying
> to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't see
> the last few as
> cause to hold up the RC (NIghtlies on branch-2 have been pretty good of
> late, see
>
> https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/
> ).
>
> Here is my question (Tosihrio?):
>
> Looking at API changes, this change looks problematic for a minor release:
>
> hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class
> package org.apache.hadoop.hbase.client
> [−] Table.mutateRow ( RowMutations rm )  *:*  void  1
>
> org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V
>
> ChangeEffect
> 1 Return value type has been changed from *void* to *Result*. This method
> has been removed because the return type is part of the method signature. A
> client program may be interrupted by *NoSuchMethodError* exception.
>
> Done here
>
> commit 3775464981b473599c6d1bb24a7eea3badf0ed03
> Author: Toshihiro Suzuki 
> Date:   Fri Nov 27 03:53:19 2020 +0900
>
> HBASE-25242 Add Increment/Append support to RowMutations (#2711)
>
> Signed-off-by: Duo Zhang 
> Signed-off-by: Andrew Purtell 
>
> The issue is called out as an incompatible change. I don't see discussion
> on why this is ok in the PRs. Was I looking in right place?
>
> S
>
> On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:
>
> > Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache hbase 2.4.0
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 2.4.0RC1:
> >
> > https://github.com/apache/hbase/tree/2.4.0RC1
> >
> > The release files, including signatures, digests, as well as CHANGES.md
> > and RELEASENOTES.md included in this RC can be found at:
> >
> > https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
> >
> > Customarily Maven artifacts would be available in a staging repository.
> > Unfortunately I was forced to terminate the Maven deploy step after
> > the upload ran for more than four hours and my build equipment
> > needed to be relocated, with loss of network connectivity. This RC has
> > been delayed long enough. A temporary Maven repository is not a
> > requirement for a vote. I will retry Maven deploy tomorrow. I can
> > promise the artifacts for this RC will be staged in Apache Nexus and
> > ready for release well ahead of the earliest possible time this vote
> > can complete.
> >
> > Artifacts were signed with the apurt...@apache.org key which can be
> found
> > in:
> >
> > https://dist.apache.org/repos/dist/release/hbase/KEYS
> >
> > The API compatibility report for this RC can be found at:
> >
> >
> >
> >
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
> >
> > The changes are mostly added methods, which conform to the compatibility
> > guidelines for a new minor release. There is one change to the public
> > Region interface that alters the return type of a method. This is
> > equivalent to a removal then addition and can be a binary compatibility
> > problem. However to your RM's eye the change looks intentional and is
> > part of an API improvement project, and a compatibility method is not
> > possible here because Java doesn't consider return type when deciding if
> > one method signature duplicates another.
> >
> > To learn more about Apache HBase, please see
> >
> > http://hbase.apache.org/
> >
> > Thanks,
> > Your HBase Release Manager
> >
>

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Stack]

+0 for now until my question below gets an answer.

Signature is good, hash is good. CHANGES and RELEASENOTES look good too.
Built from the src tgz. Artifact looks right when I untar it.
Started it in standalone mode.
UI looks good w/ nice 2.4.0 version on it (noticed new 'procedure time
statistics'... nice).
Loaded 10M rows w/ pe. Read them back out again.
I've been running unit tests over the last few days. There are flakies that
I've been trying
to fix as I see them (HBASE-25353 is latest). I'll keep at it but don't see
the last few as
cause to hold up the RC (NIghtlies on branch-2 have been pretty good of
late, see
https://ci-hadoop.apache.org/view/HBase/job/HBase/job/HBase%20Nightly/job/branch-2/
).

Here is my question (Tosihrio?):

Looking at API changes, this change looks problematic for a minor release:

hbase-shaded-client-byo-hadoop-2.3.0.jar, Table.class
package org.apache.hadoop.hbase.client
[−] Table.mutateRow ( RowMutations rm )  *:*  void  1
org/apache/hadoop/hbase/client/Table.mutateRow:(Lorg/apache/hadoop/hbase/client/RowMutations;)V

ChangeEffect
1 Return value type has been changed from *void* to *Result*. This method
has been removed because the return type is part of the method signature. A
client program may be interrupted by *NoSuchMethodError* exception.

Done here

commit 3775464981b473599c6d1bb24a7eea3badf0ed03
Author: Toshihiro Suzuki 
Date:   Fri Nov 27 03:53:19 2020 +0900

HBASE-25242 Add Increment/Append support to RowMutations (#2711)

Signed-off-by: Duo Zhang 
Signed-off-by: Andrew Purtell 

The issue is called out as an incompatible change. I don't see discussion
on why this is ok in the PRs. Was I looking in right place?

S

On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:

> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.4.0RC1:
>
> https://github.com/apache/hbase/tree/2.4.0RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
>
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
>
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> The API compatibility report for this RC can be found at:
>
>
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here because Java doesn't consider return type when deciding if
> one method signature duplicates another.
>
> To learn more about Apache HBase, please see
>
> http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>

Re: [VOTE] First release candidate for HBase 2.4.0 (RC1) is available

[Huaxiang Sun]

Thanks Andrew. Running itbll with meta replica load balance mode now, will
report back tomorrow.

Huaxiang

On Thu, Dec 3, 2020 at 4:05 PM Andrew Purtell  wrote:

> Please vote on this Apache hbase release candidate, hbase-2.4.0RC1
>
> The VOTE will remain open for at least 72 hours.
>
> [ ] +1 Release this package as Apache hbase 2.4.0
> [ ] -1 Do not release this package because ...
>
> The tag to be voted on is 2.4.0RC1:
>
> https://github.com/apache/hbase/tree/2.4.0RC1
>
> The release files, including signatures, digests, as well as CHANGES.md
> and RELEASENOTES.md included in this RC can be found at:
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/
>
> Customarily Maven artifacts would be available in a staging repository.
> Unfortunately I was forced to terminate the Maven deploy step after
> the upload ran for more than four hours and my build equipment
> needed to be relocated, with loss of network connectivity. This RC has
> been delayed long enough. A temporary Maven repository is not a
> requirement for a vote. I will retry Maven deploy tomorrow. I can
> promise the artifacts for this RC will be staged in Apache Nexus and
> ready for release well ahead of the earliest possible time this vote
> can complete.
>
> Artifacts were signed with the apurt...@apache.org key which can be found
> in:
>
> https://dist.apache.org/repos/dist/release/hbase/KEYS
>
> The API compatibility report for this RC can be found at:
>
>
>
> https://dist.apache.org/repos/dist/dev/hbase/2.4.0RC1/api_compare_2.4.0RC1_to_2.3.0.html
>
> The changes are mostly added methods, which conform to the compatibility
> guidelines for a new minor release. There is one change to the public
> Region interface that alters the return type of a method. This is
> equivalent to a removal then addition and can be a binary compatibility
> problem. However to your RM's eye the change looks intentional and is
> part of an API improvement project, and a compatibility method is not
> possible here because Java doesn't consider return type when deciding if
> one method signature duplicates another.
>
> To learn more about Apache HBase, please see
>
> http://hbase.apache.org/
>
> Thanks,
> Your HBase Release Manager
>