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
> >
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,
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
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'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
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
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
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
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
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
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
[
https://issues.apache.org/jira/browse/HBASE-25376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-25376.
---
Hadoop Flags: Reviewed
Resolution: Fixed
Merge. Thanks for review [~apurtell]
>
[
https://issues.apache.org/jira/browse/HBASE-25380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Stack resolved HBASE-25380.
---
Fix Version/s: 3.0.0-alpha-1
Hadoop Flags: Reviewed
Assignee: Michael Stack
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
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
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
> 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
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
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:
>
> $
>
[
https://issues.apache.org/jira/browse/HBASE-25362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zach York resolved HBASE-25362.
---
Fix Version/s: 3.0.0-alpha-1
Hadoop Flags: Reviewed
Resolution: Fixed
> Quoting in
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
Michael Stack created HBASE-25380:
-
Summary: [create-release] Add timestamping to log output
Key: HBASE-25380
URL: https://issues.apache.org/jira/browse/HBASE-25380
Project: HBase
Issue
Pankaj Kumar created HBASE-25379:
Summary: Make intial pause time configurable for regionserver
while sending reportRegionStateTransition
Key: HBASE-25379
URL: https://issues.apache.org/jira/browse/HBASE-25379
[
https://issues.apache.org/jira/browse/HBASE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-25372.
---
Hadoop Flags: Reviewed
Resolution: Fixed
Pushed to branch-2.4+.
Thanks [~q977734161] for
[
https://issues.apache.org/jira/browse/HBASE-25372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang reopened HBASE-25372:
---
> Fix typo in ban-jersey section of the enforcer plugin in pom.xml
>
Pankaj Kumar created HBASE-25378:
Summary: Legacy comparator in Hfile trailer will fail to load
Key: HBASE-25378
URL: https://issues.apache.org/jira/browse/HBASE-25378
Project: HBase
Issue
jackylau created HBASE-25377:
Summary: hbase arm version regionserver cpu too high and not exit
when connecting zk session timeout
Key: HBASE-25377
URL: https://issues.apache.org/jira/browse/HBASE-25377
+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
28 matches
Mail list logo
