[jira] [Updated] (HBASE-22005) Use ByteBuff's refcnt to track the life cycle of data block
[ https://issues.apache.org/jira/browse/HBASE-22005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-22005: - Attachment: HBASE-22005.HBASE-21879.v9.patch > Use ByteBuff's refcnt to track the life cycle of data block > --- > > Key: HBASE-22005 > URL: https://issues.apache.org/jira/browse/HBASE-22005 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-22005.HBASE-21879.v1.patch, > HBASE-22005.HBASE-21879.v2.patch, HBASE-22005.HBASE-21879.v3.patch, > HBASE-22005.HBASE-21879.v4.patch, HBASE-22005.HBASE-21879.v5.patch, > HBASE-22005.HBASE-21879.v6.patch, HBASE-22005.HBASE-21879.v7.patch, > HBASE-22005.HBASE-21879.v8.patch, HBASE-22005.HBASE-21879.v9.patch, > HBASE-22005.HBASE-21879.v9.patch, cell-encoding.jpeg > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22123) REST gateway reports Insufficient permissions exceptions as 404 Not Found
[
https://issues.apache.org/jira/browse/HBASE-22123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804653#comment-16804653
]
Hudson commented on HBASE-22123:
Results for branch branch-2.2
[build #141 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/141/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/141//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/141//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/141//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> REST gateway reports Insufficient permissions exceptions as 404 Not Found
> -
>
> Key: HBASE-22123
> URL: https://issues.apache.org/jira/browse/HBASE-22123
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 2.0.5
>Reporter: Tomas Sokorai
>Assignee: Tomas Sokorai
>Priority: Minor
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.0.6, 2.1.5
>
> Attachments: HBASE-22123.patch, HBASE-22123_002.patch
>
>
> When a row access is denied due to insufficient permissions, the error thrown
> to the client is 404 Not Found, instead of the proper 403 Forbidden exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20755) quickstart note about Web UI port changes in ref guide is rendered incorrectly
[
https://issues.apache.org/jira/browse/HBASE-20755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804687#comment-16804687
]
Hudson commented on HBASE-20755:
Results for branch master
[build #894 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/894/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> quickstart note about Web UI port changes in ref guide is rendered incorrectly
> --
>
> Key: HBASE-20755
> URL: https://issues.apache.org/jira/browse/HBASE-20755
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Sean Busbey
>Assignee: Subrat Mishra
>Priority: Minor
> Labels: beginner
> Fix For: 3.0.0
>
> Attachments: HBASE-20755.master.001.patch, Untitled.png
>
>
> The note in the quickstart guide about how the web ui ports changed only
> renders the title as a note. the text is just a normal paragraph afterwards.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22123) REST gateway reports Insufficient permissions exceptions as 404 Not Found
[
https://issues.apache.org/jira/browse/HBASE-22123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804690#comment-16804690
]
Hudson commented on HBASE-22123:
Results for branch master
[build #894 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/894/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> REST gateway reports Insufficient permissions exceptions as 404 Not Found
> -
>
> Key: HBASE-22123
> URL: https://issues.apache.org/jira/browse/HBASE-22123
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 2.0.5
>Reporter: Tomas Sokorai
>Assignee: Tomas Sokorai
>Priority: Minor
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.0.6, 2.1.5
>
> Attachments: HBASE-22123.patch, HBASE-22123_002.patch
>
>
> When a row access is denied due to insufficient permissions, the error thrown
> to the client is 404 Not Found, instead of the proper 403 Forbidden exception.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22053) zookeeper URL links in documentation are failing with 404
[
https://issues.apache.org/jira/browse/HBASE-22053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804688#comment-16804688
]
Hudson commented on HBASE-22053:
Results for branch master
[build #894 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/894/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> zookeeper URL links in documentation are failing with 404
> -
>
> Key: HBASE-22053
> URL: https://issues.apache.org/jira/browse/HBASE-22053
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Subrat Mishra
>Assignee: Subrat Mishra
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-22053.master.001.patch,
> HBASE-22053.master.002.patch, HBASE-22053.master.addendum.patch
>
>
> zookeeper URL changed from hadoop.apache.org to zookeeper.apache.org
> E.g: Below URL failing with 404
> http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions
> should be changed to:
> https://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkSessions
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21135) Build fails on windows as it fails to parse windows path during license check
[
https://issues.apache.org/jira/browse/HBASE-21135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804689#comment-16804689
]
Hudson commented on HBASE-21135:
Results for branch master
[build #894 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/894/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/894//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Build fails on windows as it fails to parse windows path during license check
> -
>
> Key: HBASE-21135
> URL: https://issues.apache.org/jira/browse/HBASE-21135
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 1.4.0, 1.3.2, 1.1.12, 1.2.7, 2.1.1
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Labels: cygwin
> Fix For: 3.0.0, 1.5.0, 1.6.0, 1.4.10, 1.3.4, 2.3.0, 2.0.6,
> 1.2.12, 2.1.5, 2.2.1
>
> Attachments: HBASE-21135-addendum.patch, HBASE-21135.master.001.patch
>
>
> License check via enforce plugin throws following error during build on
> windows:
> {code:java}
> Sourced file: inline evaluation of: ``File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-ar . . . '' Token
> Parsing Error: Lexical error at line 1, column 29. Encountered: "D" (68),
> after : "\"D:\\": {code}
> Complete stacktrace with command
> {code:java}
> mvn clean install -DskipTests -X
> {code}
> is as follows:
> {noformat}
> [INFO] --- maven-enforcer-plugin:3.0.0-M1:enforce (check-aggregate-license) @
> hbase-shaded ---
> [DEBUG] Configuring mojo
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce from plugin
> realm
> ClassRealm[plugin>org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1,
> parent: sun.misc.Launcher$AppClassLoader@55f96302]
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce' with basic
> configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (f) mojoExecution =
> org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M1:enforce {execution:
> check-aggregate-license}
> [DEBUG] (s) project = MavenProject:
> org.apache.hbase:hbase-shaded:2.1.1-SNAPSHOT @
> D:\DS\HBase_2\hbase\hbase-shaded\pom.xml
> [DEBUG] (s) condition = File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
> scanner.close();
> return true;
> [DEBUG] (s) message = License errors detected, for more detail find ERROR in
>
> D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE
> [DEBUG] (s) rules =
> [org.apache.maven.plugins.enforcer.EvaluateBeanshell@7e307087]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@5e1218b4
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.EvaluateBeanshell
> [DEBUG] Echo condition : File license = new
> File("D:\DS\HBase_2\hbase\hbase-shaded\target/maven-shared-archive-resources/META-INF/LICENSE");
> // Beanshell does not support try-with-resources,
> // so we must close this scanner manually
> Scanner scanner = new Scanner(license);
> while (scanner.hasNextLine()) {
> if (scanner.nextLine().startsWith("ERROR:")) {
> scanner.close();
> return false;
> }
> }
>
[jira] [Comment Edited] (HBASE-22031) Provide RSGroupInfo with a new constructor using shallow copy
[
https://issues.apache.org/jira/browse/HBASE-22031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16803006#comment-16803006
]
Xiang Li edited comment on HBASE-22031 at 3/29/19 8:25 AM:
---
Hi [~xucang] yes, it is a good question (for me) that if it worths here, or
necessary.
The shallow copy trades safety for a better performance: It is safe if we deep
copy (allocate new TreeSets and then make a copy) for tables and servers
inputted. The update on the inputs will not affect RSGroupInfo instance. But as
a trade-off, the allocation of TreeSet is heavy.
By using shallow copy, RSGroupInfo instance points the the input ones, rather
than making a copy within itself. It is fast but the subsequent update on the
inputs will also affect that RSGroupInfo instance.
If the code followed does not change the input servers and tables, it is safe
to do the shallow copy. I will review the code in the context to make sure it
is safe to do that.
was (Author: water):
Hi [~xucang] yes, it is a good question (for me) that if it worths here, or
necessary.
The shallow copy trades safety for a better performance: It is safe if we deep
copy (allocate new TreeSets and then make a copy) for tables and servers
inputted. The update on the inputs will not affect RSGroupInfo instance. But as
a trace-off, the allocation of TreeSet is heavy.
By using shallow copy, RSGroupInfo instance points the the input ones, rather
than making a copy within itself. It is fast but the subsequent update on the
inputs will also affect that RSGroupInfo instance.
If the code followed does not change the input servers and tables, it is safe
to do the shallow copy. I will review the code in the context to make sure it
is safe to do that.
> Provide RSGroupInfo with a new constructor using shallow copy
> -
>
> Key: HBASE-22031
> URL: https://issues.apache.org/jira/browse/HBASE-22031
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-22031.master.000.patch,
> HBASE-22031.master.001.patch, HBASE-22031.master.002.patch
>
>
> As for org.apache.hadoop.hbase.rsgroup.RSGroupInfo, the following constructor
> performs deep copies on both servers and tables inputed.
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfo.java.java|borderStyle=solid}
> RSGroupInfo(String name, SortedSet servers, SortedSet
> tables) {
> this.name = name;
> this.servers = (servers == null) ? new TreeSet<>() : new TreeSet<>(servers);
> this.tables = (tables == null) ? new TreeSet<>() : new TreeSet<>(tables);
> }
> {code}
> The constructor of TreeSet is heavy and I think it is better to have a new
> constructor with shallow copy and it could be used at least in
> {code:title=hbase-rsgroup/src/main/java/org/apache/hadoop/hbase/rsgroup/RSGroupInfoManagerImpl.java|borderStyle=solid}
> private synchronized void refresh(boolean forceOnline) throws IOException {
> ...
> groupList.add(new RSGroupInfo(RSGroupInfo.DEFAULT_GROUP,
> getDefaultServers(), orphanTables));
> ...
> {code}
> It is not needed to allocate new TreeSet to deep copy the output of
> getDefaultServers() and orphanTables, both of which are allocated in the near
> context and not updated in the code followed. So it is safe to make a shadow
> copy here.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Xiao reassigned HBASE-22128: - Assignee: Bing Xiao > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.1.5 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.1.5 > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22128) Move namespace region then master crashed make deadlock
Bing Xiao created HBASE-22128: - Summary: Move namespace region then master crashed make deadlock Key: HBASE-22128 URL: https://issues.apache.org/jira/browse/HBASE-22128 Project: HBase Issue Type: Bug Affects Versions: 2.1.5 Reporter: Bing Xiao Fix For: 2.1.5 When move namespace region start unassign produre, after unassign procedure finished namespace region will be offline. At the same time master crashed then reboot will stuck, because master init is block by waiting namespace table online ,at same time master init not finish so move region procedure can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bing Xiao updated HBASE-22128: -- Attachment: HBASE-22128-branch-2.1-v1.patch > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.1.5 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22121) AsyncAdmin can not deal with non default meta replica
[
https://issues.apache.org/jira/browse/HBASE-22121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804764#comment-16804764
]
Hadoop QA commented on HBASE-22121:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 4m
33s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
19s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
30s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 39s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
30s{color} | {color:green} hbase-client: The patch generated 0 new + 13
unchanged - 1 fixed = 13 total (was 14) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
5s{color} | {color:red} hbase-server: The patch generated 2 new + 10 unchanged
- 0 fixed = 12 total (was 10) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
16s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 13s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
22s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}265m 39s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
53s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}319m 38s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| | hadoop.hbase.TestSplitMerge |
| | hadoop.hbase.client.TestSnapshotTemporaryDirectoryWithRegionReplicas |
| | hadoop.hbase.client.TestSnapshotDFSTemporaryDirectory |
| | hadoop.hbase.master.TestSplitWALManager |
| | hadoop.hbase.master.TestAssignmentManagerMetrics |
| | hadoop.hbase.client.TestAsyncTableBatch |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0
[jira] [Commented] (HBASE-20662) Increasing space quota on a violated table does not remove SpaceViolationPolicy.DISABLE enforcement
[
https://issues.apache.org/jira/browse/HBASE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804771#comment-16804771
]
Nihal Jain commented on HBASE-20662:
[~Uma Murugesan] Thanks for reporting, could you please create an issue for the
same. Feel free to assign it to me, will try to have a look over the weekend. I
think a lot more bugs exits in namespace quota, which needs to be looked into.
Till now i have tried to concentrate at table quota only.
> Increasing space quota on a violated table does not remove
> SpaceViolationPolicy.DISABLE enforcement
> ---
>
> Key: HBASE-20662
> URL: https://issues.apache.org/jira/browse/HBASE-20662
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.6, 2.1.5
>
> Attachments: HBASE-20662.branch-2.1.001.patch,
> HBASE-20662.master.001.patch, HBASE-20662.master.002.patch,
> HBASE-20662.master.003.patch, HBASE-20662.master.004.patch,
> HBASE-20662.master.004.patch, HBASE-20662.master.005.patch,
> HBASE-20662.master.006.patch, HBASE-20662.master.007.patch,
> HBASE-20662.master.008.patch, HBASE-20662.master.008.patch,
> HBASE-20662.master.009.patch, HBASE-20662.master.009.patch,
> HBASE-20662.master.010.patch, screenshot.png
>
>
> *Steps to reproduce*
> * Create a table and set quota with {{SpaceViolationPolicy.DISABLE}} having
> limit say 2MB
> * Now put rows until space quota is violated and table gets disabled
> * Next, increase space quota with limit say 4MB on the table
> * Now try putting a row into the table
> {code:java}
> private void testSetQuotaThenViolateAndFinallyIncreaseQuota() throws
> Exception {
> SpaceViolationPolicy policy = SpaceViolationPolicy.DISABLE;
> Put put = new Put(Bytes.toBytes("to_reject"));
> put.addColumn(Bytes.toBytes(SpaceQuotaHelperForTests.F1),
> Bytes.toBytes("to"),
> Bytes.toBytes("reject"));
> // Do puts until we violate space policy
> final TableName tn = writeUntilViolationAndVerifyViolation(policy, put);
> // Now, increase limit
> setQuotaLimit(tn, policy, 4L);
> // Put some row now: should not violate as quota limit increased
> verifyNoViolation(policy, tn, put);
> }
> {code}
> *Expected*
> We should be able to put data as long as newly set quota limit is not reached
> *Actual*
> We fail to put any new row even after increasing limit
> *Root cause*
> Increasing quota on a violated table triggers the table to be enabled, but
> since the table is already in violation, the system does not allow it to be
> enabled (may be thinking that a user is trying to enable it)
> *Relevant exception trace*
> {noformat}
> 2018-05-31 00:34:27,563 INFO [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> client.HBaseAdmin$14(844): Started enable of
> testSetQuotaAndThenIncreaseQuotaWithDisable0
> 2018-05-31 00:34:27,571 DEBUG
> [RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=42525]
> ipc.CallRunner(142): callId: 11 service: MasterService methodName:
> EnableTable size: 104 connection: 127.0.0.1:38030 deadline: 1527707127568,
> exception=org.apache.hadoop.hbase.security.AccessDeniedException: Enabling
> the table 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to
> a violated space quota.
> 2018-05-31 00:34:27,571 ERROR [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> quotas.RegionServerSpaceQuotaManager(210): Failed to disable space violation
> policy for testSetQuotaAndThenIncreaseQuotaWithDisable0. This table will
> remain in violation.
> org.apache.hadoop.hbase.security.AccessDeniedException:
> org.apache.hadoop.hbase.security.AccessDeniedException: Enabling the table
> 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to a
> violated space quota.
> at org.apache.hadoop.hbase.master.HMaster$6.run(HMaster.java:2275)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:131)
> at org.apache.hadoop.hbase.master.HMaster.enableTable(HMaster.java:2258)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.enableTable(MasterRpcServices.java:725)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
[jira] [Created] (HBASE-22129) Rewrite TestSpaceQuotas as parameterized tests
Nihal Jain created HBASE-22129:
--
Summary: Rewrite TestSpaceQuotas as parameterized tests
Key: HBASE-22129
URL: https://issues.apache.org/jira/browse/HBASE-22129
Project: HBase
Issue Type: Improvement
Reporter: Nihal Jain
Assignee: Nihal Jain
In {{TestSpaceQuotas}}, for a particular test scenario we have a new method for
each quota type. This calls for rewriting the tests as {{Parameterized}} tests.
In this Jira I plan to split {{TestSpaceQuotas}} into:
* *{{SpaceQuotasTestBase}}*: Base class for tests
* *{{TestSpaceQuotas}}*: No-parameterized tests
* *{{TestSpaceQuotasOnTables}}*: Parameterized table space quota tests
* *{{TestSpaceQuotasOnNamespaces}}*: Parameterized namespace space quota tests
Mostly need to do what was done in [HBASE-20662 Patch 2|#file-9].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22129) Rewrite TestSpaceQuotas as parameterized tests
[
https://issues.apache.org/jira/browse/HBASE-22129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nihal Jain updated HBASE-22129:
---
Description:
In {{TestSpaceQuotas}}, for a particular test scenario we have a new method for
each quota type. This calls for rewriting the tests as {{Parameterized}} tests.
In this Jira I plan to split {{TestSpaceQuotas}} into:
* *{{SpaceQuotasTestBase}}*: Base class for tests
* *{{TestSpaceQuotas}}*: Non-parameterized tests
* *{{TestSpaceQuotasOnTables}}*: Parameterized table space quota tests
* *{{TestSpaceQuotasOnNamespaces}}*: Parameterized namespace space quota tests
Mostly need to do what was done in [^HBASE-20662.master.002.patch].
was:
In {{TestSpaceQuotas}}, for a particular test scenario we have a new method for
each quota type. This calls for rewriting the tests as {{Parameterized}} tests.
In this Jira I plan to split {{TestSpaceQuotas}} into:
* *{{SpaceQuotasTestBase}}*: Base class for tests
* *{{TestSpaceQuotas}}*: No-parameterized tests
* *{{TestSpaceQuotasOnTables}}*: Parameterized table space quota tests
* *{{TestSpaceQuotasOnNamespaces}}*: Parameterized namespace space quota tests
Mostly need to do what was done in [HBASE-20662 Patch
2|https://issues.apache.org/jira/secure/attachment/12927187/HBASE-20662.master.002.patch].
> Rewrite TestSpaceQuotas as parameterized tests
> --
>
> Key: HBASE-22129
> URL: https://issues.apache.org/jira/browse/HBASE-22129
> Project: HBase
> Issue Type: Improvement
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
>
> In {{TestSpaceQuotas}}, for a particular test scenario we have a new method
> for each quota type. This calls for rewriting the tests as {{Parameterized}}
> tests.
> In this Jira I plan to split {{TestSpaceQuotas}} into:
> * *{{SpaceQuotasTestBase}}*: Base class for tests
> * *{{TestSpaceQuotas}}*: Non-parameterized tests
> * *{{TestSpaceQuotasOnTables}}*: Parameterized table space quota tests
> * *{{TestSpaceQuotasOnNamespaces}}*: Parameterized namespace space quota
> tests
> Mostly need to do what was done in [^HBASE-20662.master.002.patch].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22129) Rewrite TestSpaceQuotas as parameterized tests
[
https://issues.apache.org/jira/browse/HBASE-22129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nihal Jain updated HBASE-22129:
---
Description:
In {{TestSpaceQuotas}}, for a particular test scenario we have a new method for
each quota type. This calls for rewriting the tests as {{Parameterized}} tests.
In this Jira I plan to split {{TestSpaceQuotas}} into:
* *{{SpaceQuotasTestBase}}*: Base class for tests
* *{{TestSpaceQuotas}}*: No-parameterized tests
* *{{TestSpaceQuotasOnTables}}*: Parameterized table space quota tests
* *{{TestSpaceQuotasOnNamespaces}}*: Parameterized namespace space quota tests
Mostly need to do what was done in [HBASE-20662 Patch
2|https://issues.apache.org/jira/secure/attachment/12927187/HBASE-20662.master.002.patch].
was:
In {{TestSpaceQuotas}}, for a particular test scenario we have a new method for
each quota type. This calls for rewriting the tests as {{Parameterized}} tests.
In this Jira I plan to split {{TestSpaceQuotas}} into:
* *{{SpaceQuotasTestBase}}*: Base class for tests
* *{{TestSpaceQuotas}}*: No-parameterized tests
* *{{TestSpaceQuotasOnTables}}*: Parameterized table space quota tests
* *{{TestSpaceQuotasOnNamespaces}}*: Parameterized namespace space quota tests
Mostly need to do what was done in [HBASE-20662 Patch 2|#file-9].
> Rewrite TestSpaceQuotas as parameterized tests
> --
>
> Key: HBASE-22129
> URL: https://issues.apache.org/jira/browse/HBASE-22129
> Project: HBase
> Issue Type: Improvement
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
>
> In {{TestSpaceQuotas}}, for a particular test scenario we have a new method
> for each quota type. This calls for rewriting the tests as {{Parameterized}}
> tests.
> In this Jira I plan to split {{TestSpaceQuotas}} into:
> * *{{SpaceQuotasTestBase}}*: Base class for tests
> * *{{TestSpaceQuotas}}*: No-parameterized tests
> * *{{TestSpaceQuotasOnTables}}*: Parameterized table space quota tests
> * *{{TestSpaceQuotasOnNamespaces}}*: Parameterized namespace space quota
> tests
> Mostly need to do what was done in [HBASE-20662 Patch
> 2|https://issues.apache.org/jira/secure/attachment/12927187/HBASE-20662.master.002.patch].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22005) Use ByteBuff's refcnt to track the life cycle of data block
[
https://issues.apache.org/jira/browse/HBASE-22005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804792#comment-16804792
]
Hadoop QA commented on HBASE-22005:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 15 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
33s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
0s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
21s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
11s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
2s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{color} | {color:green} HBASE-21879 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
25s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 44s{color}
| {color:red} hbase-server generated 1 new + 193 unchanged - 1 fixed = 194
total (was 194) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{color} | {color:green} The patch passed checkstyle in hbase-common {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
8s{color} | {color:green} hbase-server: The patch generated 0 new + 229
unchanged - 6 fixed = 229 total (was 235) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
10s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 6s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
40s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}291m 24s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
37s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}338m 35s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestSCPWithReplicasWithoutZKCoordinated |
| | hadoop.hbase.client.TestAsyncDecommissionAdminApi |
| | hadoop.hbase.io.encoding.TestLoadAndSwitchEncodeOnDisk |
| |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleWAL |
| | hadoop.hbase.master.TestRestartCluster |
| | hadoop.hbase.replication.TestReplicationSyncUpTool |
| | hadoop.hbase.regionserver.TestSplitTransactionOnCluster |
[jira] [Commented] (HBASE-21818) a document write misstack
[
https://issues.apache.org/jira/browse/HBASE-21818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804838#comment-16804838
]
Peter Somogyi commented on HBASE-21818:
---
Hi [~iamgd67], branch-1.1 is EOL. Could you try to attach a patch using
dev-support/submit-patch.py instead targeting a patch for branch-1? Intellij
does not have the same patch format and it does not have your commit
informations in it (e.g. name, email address).
> a document write misstack
> -
>
> Key: HBASE-21818
> URL: https://issues.apache.org/jira/browse/HBASE-21818
> Project: HBase
> Issue Type: Improvement
> Components: documentation, master
>Affects Versions: 1.1.0, 2.0.1
> Environment: has nothing to do with env
>Reporter: qiang Liu
>Priority: Trivial
> Labels: easyfix, javadoc
> Fix For: 2.0.2
>
> Attachments: HBASE-21818.branch-1.001.patch,
> HBASE-21818.branch-1.1.001.patch, HBASE-21818.branch-1.1.002.patch,
> blankLineOfJavaDoc.png
>
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> the java doc of this function type a as ，so dispaly a blanck line
> {code:java}
> //org.apache.hadoop.hbase.master.HMaster#finishActiveMasterInitialization
> {code}
> paste the function and it's doc here , please look the line "Ensure
> assignment of meta/namespace regions"
>
>
> {code:java}
> /**
> * Finish initialization of HMaster after becoming the primary master.
> *
> *
> * Initialize master components - file system manager, server manager,
> * assignment manager, region server tracker, etc
> * Start necessary service threads - balancer, catalog janior,
> * executor services, etc
> * Set cluster as UP in ZooKeeper
> * Wait for RegionServers to check-in
> * Split logs and perform data recovery, if necessary
> * Ensure assignment of meta/namespace regions
> * Handle either fresh cluster start or master failover
> *
> *
> * @throws IOException
> * @throws InterruptedException
> * @throws KeeperException
> * @throws CoordinatedStateException
> */
> private void finishActiveMasterInitialization(MonitoredTask status)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-21818) a document write misstack
[
https://issues.apache.org/jira/browse/HBASE-21818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi reassigned HBASE-21818:
-
Assignee: qiang Liu
> a document write misstack
> -
>
> Key: HBASE-21818
> URL: https://issues.apache.org/jira/browse/HBASE-21818
> Project: HBase
> Issue Type: Improvement
> Components: documentation, master
>Affects Versions: 1.1.0, 2.0.1
> Environment: has nothing to do with env
>Reporter: qiang Liu
>Assignee: qiang Liu
>Priority: Trivial
> Labels: easyfix, javadoc
> Fix For: 2.0.2
>
> Attachments: HBASE-21818.branch-1.001.patch,
> HBASE-21818.branch-1.1.001.patch, HBASE-21818.branch-1.1.002.patch,
> blankLineOfJavaDoc.png
>
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> the java doc of this function type a as ，so dispaly a blanck line
> {code:java}
> //org.apache.hadoop.hbase.master.HMaster#finishActiveMasterInitialization
> {code}
> paste the function and it's doc here , please look the line "Ensure
> assignment of meta/namespace regions"
>
>
> {code:java}
> /**
> * Finish initialization of HMaster after becoming the primary master.
> *
> *
> * Initialize master components - file system manager, server manager,
> * assignment manager, region server tracker, etc
> * Start necessary service threads - balancer, catalog janior,
> * executor services, etc
> * Set cluster as UP in ZooKeeper
> * Wait for RegionServers to check-in
> * Split logs and perform data recovery, if necessary
> * Ensure assignment of meta/namespace regions
> * Handle either fresh cluster start or master failover
> *
> *
> * @throws IOException
> * @throws InterruptedException
> * @throws KeeperException
> * @throws CoordinatedStateException
> */
> private void finishActiveMasterInitialization(MonitoredTask status)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-22128: -- Status: Patch Available (was: Open) > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.1.5 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22128) Move namespace region then master crashed make deadlock
[ https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804846#comment-16804846 ] Peter Somogyi commented on HBASE-22128: --- Moved to Patch available. > Move namespace region then master crashed make deadlock > --- > > Key: HBASE-22128 > URL: https://issues.apache.org/jira/browse/HBASE-22128 > Project: HBase > Issue Type: Bug >Affects Versions: 2.1.5 >Reporter: Bing Xiao >Assignee: Bing Xiao >Priority: Critical > Fix For: 2.1.5 > > Attachments: HBASE-22128-branch-2.1-v1.patch > > > When move namespace region start unassign produre, after unassign procedure > finished namespace region will be offline. At the same time master crashed > then reboot will stuck, because master init is block by waiting namespace > table online ,at same time master init not finish so move region procedure > can not go on, make deadlock. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22124) Optimize the performance for region moving
[
https://issues.apache.org/jira/browse/HBASE-22124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
kevin su updated HBASE-22124:
-
Attachment: HBASE-22124.v0.patch
> Optimize the performance for region moving
> --
>
> Key: HBASE-22124
> URL: https://issues.apache.org/jira/browse/HBASE-22124
> Project: HBase
> Issue Type: Improvement
>Reporter: Duo Zhang
>Priority: Major
> Attachments: HBASE-22124.v0.patch
>
>
> It is an admin operation so we do not care much about the performance in the
> past, but it is really important for rolling upgrade.
> For AsyncAdmin, if encoded name is present at client side, we will always
> scan the whole meta region to find the region record first, which is really
> expensive for a large cluster.
> And we always send the encoded name to master, so at master side, we still
> need the encoded name -> region name converting, and it is still very
> expensive
> {code}
> public RegionState getRegionState(final String encodedRegionName) {
> // TODO: Need a map but it is just dispatch merge...
> for (RegionStateNode node: regionsMap.values()) {
> if (node.getRegionInfo().getEncodedName().equals(encodedRegionName)) {
> return node.toRegionState();
> }
> }
> return null;
> }
> {code}
> Need to fix them both.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22124) Optimize the performance for region moving
[
https://issues.apache.org/jira/browse/HBASE-22124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804887#comment-16804887
]
kevin su commented on HBASE-22124:
--
Use ConcurrentSkipListMap to save RegionStateNode, and Encodedname as a key.
Everytime createRegionStateNode put to
ConcurrentSkipListMap.
So we can use this map to Optimize the performance, but use more memory.
> Optimize the performance for region moving
> --
>
> Key: HBASE-22124
> URL: https://issues.apache.org/jira/browse/HBASE-22124
> Project: HBase
> Issue Type: Improvement
>Reporter: Duo Zhang
>Priority: Major
> Attachments: HBASE-22124.v0.patch
>
>
> It is an admin operation so we do not care much about the performance in the
> past, but it is really important for rolling upgrade.
> For AsyncAdmin, if encoded name is present at client side, we will always
> scan the whole meta region to find the region record first, which is really
> expensive for a large cluster.
> And we always send the encoded name to master, so at master side, we still
> need the encoded name -> region name converting, and it is still very
> expensive
> {code}
> public RegionState getRegionState(final String encodedRegionName) {
> // TODO: Need a map but it is just dispatch merge...
> for (RegionStateNode node: regionsMap.values()) {
> if (node.getRegionInfo().getEncodedName().equals(encodedRegionName)) {
> return node.toRegionState();
> }
> }
> return null;
> }
> {code}
> Need to fix them both.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-22073:
Attachment: HBASE-22073.master.patch
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804912#comment-16804912
]
Balazs Meszaros commented on HBASE-22073:
-
Hey [~stack], good to see you!
I attached a new patch for master (it can and should be applied to branch-2.2).
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21879) Read HFile's block to ByteBuffer directly instead of to byte for reducing young gc purpose
[
https://issues.apache.org/jira/browse/HBASE-21879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804917#comment-16804917
]
Hudson commented on HBASE-21879:
Results for branch HBASE-21879
[build #42 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/42/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/42//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/42//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/42//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Read HFile's block to ByteBuffer directly instead of to byte for reducing
> young gc purpose
> --
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
> Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21879.v1.patch, HBASE-21879.v1.patch,
> QPS-latencies-before-HBASE-21879.png, gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal, we have the following:
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum,
> boolean updateMetrics)
> throws IOException {
> // .
> // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with
> BBPool (offheap).
> byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
> int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
> onDiskSizeWithHeader - preReadHeaderSize, true, offset +
> preReadHeaderSize, pread);
> if (headerBuf != null) {
> // ...
> }
> // ...
> }
> {code}
> In the read path, we still read the block from hfile to on-heap byte[], then
> copy the on-heap byte[] to offheap bucket cache asynchronously, and in my
> 100% get performance test, I also observed some frequent young gc, The
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to
> byte[] for reducing young gc purpose. we did not implement this before,
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+
> has supported this now, so we can fix this now. I think.
> Will provide an patch and some perf-comparison for this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22121) AsyncAdmin can not deal with non default meta replica
[ https://issues.apache.org/jira/browse/HBASE-22121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22121: -- Attachment: HBASE-22121.patch > AsyncAdmin can not deal with non default meta replica > - > > Key: HBASE-22121 > URL: https://issues.apache.org/jira/browse/HBASE-22121 > Project: HBase > Issue Type: Bug > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.5 > > Attachments: HBASE-22121.patch, HBASE-22121.patch > > > In AsyncAdmin we support passing both encodedRegionName and regionName as a > parameter so we have a getRegionInfo method to get the RegionInfo first. > In general we will scan the meta table to get the region info, but for meta > region itself, the problem is that, we only check for the first replica, so > for the non default replicas, we will still go to the meta region and then > get an UnknownRegionException. > We should find a way to deal with this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22121) AsyncAdmin can not deal with non default meta replica
[ https://issues.apache.org/jira/browse/HBASE-22121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804919#comment-16804919 ] Duo Zhang commented on HBASE-22121: --- The error prone warning is still a bit unstable...Not sure why, maybe we should open an issue on the error prone project as we have already upgraded to the newest version... > AsyncAdmin can not deal with non default meta replica > - > > Key: HBASE-22121 > URL: https://issues.apache.org/jira/browse/HBASE-22121 > Project: HBase > Issue Type: Bug > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.5 > > Attachments: HBASE-22121.patch, HBASE-22121.patch > > > In AsyncAdmin we support passing both encodedRegionName and regionName as a > parameter so we have a getRegionInfo method to get the RegionInfo first. > In general we will scan the meta table to get the region info, but for meta > region itself, the problem is that, we only check for the first replica, so > for the non default replicas, we will still go to the meta region and then > get an UnknownRegionException. > We should find a way to deal with this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22005) Use ByteBuff's refcnt to track the life cycle of data block
[
https://issues.apache.org/jira/browse/HBASE-22005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804931#comment-16804931
]
Hadoop QA commented on HBASE-22005:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
33s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 16 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
46s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
2s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
26s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
54s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
5s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} HBASE-21879 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
15s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 37s{color}
| {color:red} hbase-server generated 7 new + 187 unchanged - 7 fixed = 194
total (was 194) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} The patch passed checkstyle in hbase-common {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s{color} | {color:green} hbase-server: The patch generated 0 new + 229
unchanged - 6 fixed = 229 total (was 235) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
23s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 5s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
39s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}293m 40s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
48s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}344m 56s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncDecommissionAdminApi |
| | hadoop.hbase.client.TestAsyncTableGetMultiThreaded |
| | hadoop.hbase.regionserver.TestSplitTransactionOnCluster |
| | hadoop.hbase.master.procedure.TestSCPWithReplicas |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleWAL |
| | hadoop.hbase.client.TestFromClientSide |
| | hadoop.hbase.cl
[jira] [Created] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
Duo Zhang created HBASE-22130: - Summary: [hbase-thirdparty] Upgrade thirdparty dependencies Key: HBASE-22130 URL: https://issues.apache.org/jira/browse/HBASE-22130 Project: HBase Issue Type: Task Components: thirdparty Reporter: Duo Zhang First guava has a CVE so we need to upgrade to at least 26.0, better to the newest 27.1. And we can also upgrade the other dependencies to the newest version at the same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804947#comment-16804947 ] Duo Zhang commented on HBASE-22130: --- I think we can upgrade netty to the newest 4.1.x. And do we need to upgrade protobuf? It seems that the newest version is 3.7.0 now. > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Priority: Major > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
Duo Zhang created HBASE-22131: - Summary: Delete the patches in hbase-protocol-shaded module Key: HBASE-22131 URL: https://issues.apache.org/jira/browse/HBASE-22131 Project: HBase Issue Type: Task Reporter: Duo Zhang As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805030#comment-16805030
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #154 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/154/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/154//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/154//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/154//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22128) Move namespace region then master crashed make deadlock
[
https://issues.apache.org/jira/browse/HBASE-22128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805037#comment-16805037
]
Hadoop QA commented on HBASE-22128:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-2.1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
7s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
51s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
5s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
51s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
8s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} branch-2.1 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
52s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
7s{color} | {color:red} hbase-server: The patch generated 84 new + 2 unchanged
- 0 fixed = 86 total (was 2) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
52s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
7m 51s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}139m 58s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
32s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}176m 8s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.locking.TestLockManager |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-22128 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964157/HBASE-22128-branch-2.1-v1.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux a7b5c3eee8f3 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.1 / 6218fab4aa |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/16585/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/16585/artifact/patchprocess/patc
[jira] [Reopened] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack reopened HBASE-22073:
---
Reopen to apply master branch version (Wave [~balazs.meszaros]!)
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-22073.
---
Resolution: Fixed
Pushe on branch-2.2+. Thanks for patch [~balazs.meszaros]
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-11768) Register region server in zookeeper by ip address
[
https://issues.apache.org/jira/browse/HBASE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805107#comment-16805107
]
ChenKai commented on HBASE-11768:
-
[~stack]
We run HBase cluster on k8s, and it seems to get the wrong ip(hostname) back
with this patch when invoking *regionServerStartup* and
*handleReportForDutyResponse* method.
The error is {color:red}"Master passed us a different hostname to use;
x"{color}.
I am not sure if there's something wrong with k8s DNS, so we returned and use
*hbase.master(regionserver).hostname*.
> Register region server in zookeeper by ip address
> -
>
> Key: HBASE-11768
> URL: https://issues.apache.org/jira/browse/HBASE-11768
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Cheney Sun
>Priority: Major
> Labels: patch
> Attachments: HBASE-11768.master.001.patch, HBASE_11768.patch
>
>
> HBase cluster isn't always setup along with a DNS server. But regionservers
> now register their hostnames in zookeeper, which bring some inconvenience
> when regionserver isn't in one DNS server. In such situation, clients have to
> maintain the ip/hostname mapping in their /etc/hosts files in order to
> resolve the hostname returned from zookeeper to the right address.
> However, this causes a lot of pain for clients to maintain the mapping,
> especially when adding new machines to the cluster, or some machines' address
> changed due to some reason. All clients need to update their host mapping
> files.
> The issue is to address this problem above, and try to add an option to let
> each regionserver record themself by ip address, instead of hostname only.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kevin su reassigned HBASE-22130: Assignee: kevin su > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805128#comment-16805128 ] kevin su commented on HBASE-22131: -- [~Apache9]Do you mean delete whole patches in the hbase/hbase-protocol-shaded/src/main/patches/ directory ? > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Priority: Major > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-11768) Register region server in zookeeper by ip address
[ https://issues.apache.org/jira/browse/HBASE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805140#comment-16805140 ] stack commented on HBASE-11768: --- Say more [~514793...@qq.com]. I'd think you'd want IPs rather than names if k8s but hbase (and hadoop) don't behave as far as k8s is concerned when it comes to addresses and namings. This old issue is good on the problem https://github.com/kubernetes/dns/issues/266 I'd be up for helping out here, putting a more friendly k8s behavior behind a flag Regards the complaint you see above, the Master tells RS what name to use after it checks in. In your case, it seems like the RS is not doing this. Paste a bit more log around a RS connecting to cluster and I'd be up for taking a look. Other issues making stuff work on k8s [~514793...@qq.com]? > Register region server in zookeeper by ip address > - > > Key: HBASE-11768 > URL: https://issues.apache.org/jira/browse/HBASE-11768 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Cheney Sun >Priority: Major > Labels: patch > Attachments: HBASE-11768.master.001.patch, HBASE_11768.patch > > > HBase cluster isn't always setup along with a DNS server. But regionservers > now register their hostnames in zookeeper, which bring some inconvenience > when regionserver isn't in one DNS server. In such situation, clients have to > maintain the ip/hostname mapping in their /etc/hosts files in order to > resolve the hostname returned from zookeeper to the right address. > However, this causes a lot of pain for clients to maintain the mapping, > especially when adding new machines to the cluster, or some machines' address > changed due to some reason. All clients need to update their host mapping > files. > The issue is to address this problem above, and try to add an option to let > each regionserver record themself by ip address, instead of hostname only. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805163#comment-16805163 ] stack commented on HBASE-22131: --- He means these [~pingsutw] $ ls src/main/patches/ HBASE-15789_V2.patchHBASE-17087.patch HBASE-17239.patch under hbase-protocol-shaded. They are not used anymore, not in core hbase. They are applied over in hbase-thirdparty repo. (We should probably do an hbase-thirdparty update soon and reexamine which of these patches we still need...) > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Priority: Major > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kevin su reassigned HBASE-22131: Assignee: kevin su > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805173#comment-16805173 ] kevin su commented on HBASE-22131: -- @stack Thanks for your reply, very aprreciate. I think I can take this. I will also research those patch for more detail > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22119) Provide functions in RSGroupInfo to check if a group is the default group
[
https://issues.apache.org/jira/browse/HBASE-22119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-22119:
-
Status: Patch Available (was: Open)
> Provide functions in RSGroupInfo to check if a group is the default group
> -
>
> Key: HBASE-22119
> URL: https://issues.apache.org/jira/browse/HBASE-22119
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-22119.branch-1.000.patch,
> HBASE-22119.master.000.patch
>
>
> There are several places to check if a group is the "default" group, where
> the input could be a String or a RSGroupInfo.
> It is better to provide official functions in RSGroupInfo to tell if a group
> is the default group, so as to
> * Simply the code
> * Make it more safe. It is not safe as there is no null check like
> {code}
> if (!group.getName().equals(RSGroupInfo.DEFAULT_GROUP))
> {code}
> It is more safe to check like:
> {code}
> RSGroupInfo.DEFAULT_GROUP.equals(group.getName())
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22119) Provide functions in RSGroupInfo to check if a group is the default group
[
https://issues.apache.org/jira/browse/HBASE-22119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-22119:
-
Status: Open (was: Patch Available)
> Provide functions in RSGroupInfo to check if a group is the default group
> -
>
> Key: HBASE-22119
> URL: https://issues.apache.org/jira/browse/HBASE-22119
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-22119.branch-1.000.patch,
> HBASE-22119.master.000.patch
>
>
> There are several places to check if a group is the "default" group, where
> the input could be a String or a RSGroupInfo.
> It is better to provide official functions in RSGroupInfo to tell if a group
> is the default group, so as to
> * Simply the code
> * Make it more safe. It is not safe as there is no null check like
> {code}
> if (!group.getName().equals(RSGroupInfo.DEFAULT_GROUP))
> {code}
> It is more safe to check like:
> {code}
> RSGroupInfo.DEFAULT_GROUP.equals(group.getName())
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22119) Provide functions in RSGroupInfo to check if a group is the default group
[
https://issues.apache.org/jira/browse/HBASE-22119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-22119:
-
Attachment: HBASE-22119.branch-1.000.patch
> Provide functions in RSGroupInfo to check if a group is the default group
> -
>
> Key: HBASE-22119
> URL: https://issues.apache.org/jira/browse/HBASE-22119
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-22119.branch-1.000.patch,
> HBASE-22119.master.000.patch
>
>
> There are several places to check if a group is the "default" group, where
> the input could be a String or a RSGroupInfo.
> It is better to provide official functions in RSGroupInfo to tell if a group
> is the default group, so as to
> * Simply the code
> * Make it more safe. It is not safe as there is no null check like
> {code}
> if (!group.getName().equals(RSGroupInfo.DEFAULT_GROUP))
> {code}
> It is more safe to check like:
> {code}
> RSGroupInfo.DEFAULT_GROUP.equals(group.getName())
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22119) Provide functions in RSGroupInfo to check if a group is the default group
[
https://issues.apache.org/jira/browse/HBASE-22119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805183#comment-16805183
]
Xiang Li commented on HBASE-22119:
--
[~xucang] patch for branch-1 is uploaded. Please help to review, thanks!
> Provide functions in RSGroupInfo to check if a group is the default group
> -
>
> Key: HBASE-22119
> URL: https://issues.apache.org/jira/browse/HBASE-22119
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-22119.branch-1.000.patch,
> HBASE-22119.master.000.patch
>
>
> There are several places to check if a group is the "default" group, where
> the input could be a String or a RSGroupInfo.
> It is better to provide official functions in RSGroupInfo to tell if a group
> is the default group, so as to
> * Simply the code
> * Make it more safe. It is not safe as there is no null check like
> {code}
> if (!group.getName().equals(RSGroupInfo.DEFAULT_GROUP))
> {code}
> It is more safe to check like:
> {code}
> RSGroupInfo.DEFAULT_GROUP.equals(group.getName())
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-11768) Register region server in zookeeper by ip address
[ https://issues.apache.org/jira/browse/HBASE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805195#comment-16805195 ] ChenKai commented on HBASE-11768: - [~stack] Now we use k8s's $POD_NAME + SERVICE_NAME to config *hbase.master(regionserver).hostname*, and it seems to work well. I will run some spark jobs to do more production tests, and give feedback when I encounter problems. I think this feature of registering (pod) ip to zk is very good. I will try later and give you more error messages, thanks. > Register region server in zookeeper by ip address > - > > Key: HBASE-11768 > URL: https://issues.apache.org/jira/browse/HBASE-11768 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Cheney Sun >Priority: Major > Labels: patch > Attachments: HBASE-11768.master.001.patch, HBASE_11768.patch > > > HBase cluster isn't always setup along with a DNS server. But regionservers > now register their hostnames in zookeeper, which bring some inconvenience > when regionserver isn't in one DNS server. In such situation, clients have to > maintain the ip/hostname mapping in their /etc/hosts files in order to > resolve the hostname returned from zookeeper to the right address. > However, this causes a lot of pain for clients to maintain the mapping, > especially when adding new machines to the cluster, or some machines' address > changed due to some reason. All clients need to update their host mapping > files. > The issue is to address this problem above, and try to add an option to let > each regionserver record themself by ip address, instead of hostname only. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22119) Provide functions in RSGroupInfo to check if a group is the default group
[
https://issues.apache.org/jira/browse/HBASE-22119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805214#comment-16805214
]
Hadoop QA commented on HBASE-22119:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
47s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
13s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
16s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
32s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
13s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} the patch passed with JDK v1.7.0_211 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
27s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
1m 34s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
11s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} the patch passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
50s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 29m 21s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:61288f8 |
| JIRA Issue | HBASE-22119 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964215/HBASE-22119.branch-1.000.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux c5ea1278ccbc 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
|
[jira] [Commented] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805231#comment-16805231 ] stack commented on HBASE-22130: --- The last release was a year ago. Could we get a release of hbase-thirdparty done for 2.2.0? ([~zghaobac] -- what you think?) Could update some of these mvn plugins in the poms. No harm in pb update. Seems to be just bug fixes... not much done in java. Yeah on netty... from 4.1.17 to 4.1.34 Let me put up a patch > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22130: -- Attachment: 0001-HBASE-22130-hbase-thirdparty-Upgrade-thirdparty-depe.patch > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > Attachments: > 0001-HBASE-22130-hbase-thirdparty-Upgrade-thirdparty-depe.patch > > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805237#comment-16805237 ] stack commented on HBASE-22130: --- .0001 Updates: gson 2.8.1 -> 2.8.5 guava 22.0 -> 27.1-jre pb 3.5.1 -> 3.7.0 netty 4.1.17 -> 4.1.34 commons-collections4 4.1 -> 4.3 Updated apache parent pom from 18 to 21 and misc plugins. Next would be putting up an RC. > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > Attachments: > 0001-HBASE-22130-hbase-thirdparty-Upgrade-thirdparty-depe.patch > > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-11768) Register region server in zookeeper by ip address
[ https://issues.apache.org/jira/browse/HBASE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805246#comment-16805246 ] stack commented on HBASE-11768: --- Ok. Am interested [~514793...@qq.com] in problems around this area sir. > Register region server in zookeeper by ip address > - > > Key: HBASE-11768 > URL: https://issues.apache.org/jira/browse/HBASE-11768 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Cheney Sun >Priority: Major > Labels: patch > Attachments: HBASE-11768.master.001.patch, HBASE_11768.patch > > > HBase cluster isn't always setup along with a DNS server. But regionservers > now register their hostnames in zookeeper, which bring some inconvenience > when regionserver isn't in one DNS server. In such situation, clients have to > maintain the ip/hostname mapping in their /etc/hosts files in order to > resolve the hostname returned from zookeeper to the right address. > However, this causes a lot of pain for clients to maintain the mapping, > especially when adding new machines to the cluster, or some machines' address > changed due to some reason. All clients need to update their host mapping > files. > The issue is to address this problem above, and try to add an option to let > each regionserver record themself by ip address, instead of hostname only. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805247#comment-16805247 ] stack commented on HBASE-22131: --- Checkout hbase-thirdparty and see the patches in use there too... Sorry if I stepped on your toes over in "HBASE-22130 [hbase-thirdparty] Upgrade thirdparty dependencies" > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22099) Backport HBASE-21895 "Error prone upgrade" to branch-2
[ https://issues.apache.org/jira/browse/HBASE-22099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805254#comment-16805254 ] stack commented on HBASE-22099: --- Looks great. Retrying. > Backport HBASE-21895 "Error prone upgrade" to branch-2 > -- > > Key: HBASE-22099 > URL: https://issues.apache.org/jira/browse/HBASE-22099 > Project: HBase > Issue Type: Task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.2.0, 2.3.0, 2.0.6, 2.1.5 > > Attachments: HBASE-22099-branch-2.patch, HBASE-22099-branch-2.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22099) Backport HBASE-21895 "Error prone upgrade" to branch-2
[ https://issues.apache.org/jira/browse/HBASE-22099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-22099: -- Attachment: HBASE-22099-branch-2.patch > Backport HBASE-21895 "Error prone upgrade" to branch-2 > -- > > Key: HBASE-22099 > URL: https://issues.apache.org/jira/browse/HBASE-22099 > Project: HBase > Issue Type: Task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.2.0, 2.3.0, 2.0.6, 2.1.5 > > Attachments: HBASE-22099-branch-2.patch, HBASE-22099-branch-2.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22121) AsyncAdmin can not deal with non default meta replica
[
https://issues.apache.org/jira/browse/HBASE-22121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805278#comment-16805278
]
Hadoop QA commented on HBASE-22121:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 5m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
34s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
47s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
4s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
39s{color} | {color:green} hbase-client: The patch generated 0 new + 13
unchanged - 1 fixed = 13 total (was 14) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
22s{color} | {color:red} hbase-server: The patch generated 2 new + 10 unchanged
- 0 fixed = 12 total (was 10) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
32s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 5s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
47s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}251m 29s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}321m 11s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAdmin1 |
| | hadoop.hbase.client.TestFromClientSideWithCoprocessor |
| | hadoop.hbase.client.TestFromClientSide |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22121 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964184/HBASE-22121.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checksty
[jira] [Commented] (HBASE-22099) Backport HBASE-21895 "Error prone upgrade" to branch-2
[
https://issues.apache.org/jira/browse/HBASE-22099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805346#comment-16805346
]
Hadoop QA commented on HBASE-22099:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 2m
24s{color} | {color:red} root in branch-2 failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 2m
39s{color} | {color:red} root in branch-2 failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
55s{color} | {color:green} branch-2 passed {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 2m
50s{color} | {color:red} branch has 14 errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-build-support hbase-build-configuration . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
26s{color} | {color:red} hbase-server in branch-2 failed. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
20s{color} | {color:red} hbase-mapreduce in branch-2 failed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
58s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 2m
12s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 4m
31s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 4m 31s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
7s{color} | {color:green} The patch passed checkstyle in
hbase-build-configuration {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s{color} | {color:green} The patch passed checkstyle in hbase-protocol-shaded
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} hbase-procedure: The patch generated 0 new + 3
unchanged - 1 fixed = 3 total (was 4) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} The patch passed checkstyle in hbase-server {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} hbase-mapreduce: The patch generated 0 new + 0
unchanged - 1 fixed = 0 total (was 1) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
51s{color} | {color:green} root: The patch generated 0 new + 40 unchanged - 2
fixed = 40 total (was 42) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
4s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 2m
46s{color} | {color:red} patch has 14 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
33s{color} | {color:red} The patch causes 14 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
13s{color} | {color:red} The patch causes 14 errors with Hadoop v3.0.0. {color}
|
| {color:blue}0{color} | {color:blue} findbugs {color} | {color
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805359#comment-16805359
]
Hudson commented on HBASE-22073:
Results for branch branch-2.2
[build #142 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/142/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/142//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/142//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/142//JDK8_Nightly_Build_Report_(Hadoop3)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/142//console].
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805424#comment-16805424
]
Hudson commented on HBASE-22073:
Results for branch branch-2
[build #1785 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1785/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1785//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1785//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1785//JDK8_Nightly_Build_Report_(Hadoop3)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1785//console].
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kevin su reassigned HBASE-22130: Assignee: stack (was: kevin su) > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Attachments: > 0001-HBASE-22130-hbase-thirdparty-Upgrade-thirdparty-depe.patch > > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805431#comment-16805431 ] kevin su commented on HBASE-22131: -- [~stack] Actually, I just faced some trouble about HBASE-22130, thanks for rescuing. > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22115) HBase RPC aspires to grow an infinite tree of trace scopes; some other places are also unsafe
[ https://issues.apache.org/jira/browse/HBASE-22115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22115: - Resolution: Fixed Fix Version/s: 2.2.1 2.3.0 3.0.0 Status: Resolved (was: Patch Available) Tests appear to be flaky, didn't fail on the first run and the only difference is whitespace warnings. Committed to branch-2, branch-2.2, and master, thanks for the reviews! > HBase RPC aspires to grow an infinite tree of trace scopes; some other places > are also unsafe > - > > Key: HBASE-22115 > URL: https://issues.apache.org/jira/browse/HBASE-22115 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Fix For: 3.0.0, 2.3.0, 2.2.1 > > Attachments: Clipboard01.jpg, HBASE-22115.01.patch, > HBASE-22115.02.patch, HBASE-22115.patch > > > !Clipboard01.jpg! > All of those are ClientServices.Multi in this case. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22132) Backport HBASE-22115 intent to branch-1
Andrew Purtell created HBASE-22132: -- Summary: Backport HBASE-22115 intent to branch-1 Key: HBASE-22132 URL: https://issues.apache.org/jira/browse/HBASE-22132 Project: HBase Issue Type: Sub-task Affects Versions: 1.5.0 Reporter: Andrew Purtell Fix For: 1.5.1 Check the exposure of branch-1 code to the problems described on HBASE-22115 and apply the fix approach there. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18995) Move methods that are for internal usage from CellUtil to Private util class
[
https://issues.apache.org/jira/browse/HBASE-18995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805467#comment-16805467
]
Thomas D'Silva commented on HBASE-18995:
[~ram_krish] In HBase 2.0 since {{CellUtil.setTimestamp}} has been deprecated,
what is the correct way to set the timestamp of a cell from a coprocessor?
Phoenix uses this for our mutable indexing coprocessor (see PHOENIX-5219).
FYI [~abhishek.chouhan] and [~lhofhansl]
> Move methods that are for internal usage from CellUtil to Private util class
>
>
> Key: HBASE-18995
> URL: https://issues.apache.org/jira/browse/HBASE-18995
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 2.0.0-alpha-3
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0-alpha-4, 2.0.0
>
> Attachments: HBASE-18995-branch-2.002.patch,
> HBASE-18995-branch-2.patch, HBASE-18995-branch-2_1.patch,
> HBASE-18995-branch-2_1.patch, HBASE-18995-branch-2_1.patch,
> HBASE-18995-branch-2_1.patch, HBASE-18995-branch-2_2.patch,
> HBASE-18995_002-branch-2.patch, HBASE-18995_002-branch-2.patch,
> HBASE-18995_003-branch-2.patch, HBASE-18995_1.patch, HBASE-18995_2.patch,
> HBASE-18995_2.patch
>
>
> This was brought up long time back. We need to move some of the public APIs
> from CellUtil to internal private Util class because they are used in some
> internal flow and does not make sense to have it in a @public exposed Util
> class.
> The topic again came in HBASE-18945 RB comments also.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22114) Port HBASE-15560 (TinyLFU-based BlockCache) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-22114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805493#comment-16805493
]
Sean Busbey commented on HBASE-22114:
-
the rat failures (which I think are causing most of the above failures) are
because the rat module only ignores {{target/}} directories for modules.
Because we do a jdk8 check we see the module and build it. So when we're using
jdk7 the new tinylfu module is not defined, so the {{target/}} output is
checked and fails.
> Port HBASE-15560 (TinyLFU-based BlockCache) to branch-1
> ---
>
> Key: HBASE-22114
> URL: https://issues.apache.org/jira/browse/HBASE-22114
> Project: HBase
> Issue Type: Sub-task
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-22114-branch-1.patch
>
>
> HBASE-15560 introduces the TinyLFU cache policy for the blockcache.
> W-TinyLFU ([research paper|http://arxiv.org/pdf/1512.00727.pdf]) records the
> frequency in a counting sketch, ages periodically by halving the counters,
> and orders entries by SLRU. An entry is discarded by comparing the frequency
> of the new arrival (candidate) to the SLRU's victim, and keeping the one with
> the highest frequency. This allows the operations to be performed in O(1)
> time and, though the use of a compact sketch, a much larger history is
> retained beyond the current working set. In a variety of real world traces
> the policy had [near optimal hit
> rates|https://github.com/ben-manes/caffeine/wiki/Efficiency].
> The implementation of HBASE-15560 uses several Java 8 idioms, depends on JRE
> 8+ type Optional, and has dependencies on libraries compiled with Java 8+
> bytecode. It could be backported to branch-1 but must be made optional both
> at compile time and runtime, enabled by the 'build-with-jdk8' build profile.
> The TinyLFU policy must go into its own build module.
> The blockcache must be modified to load L1 implementation/policy dynamically
> at startup by reflection if the policy is "TinyLFU"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-18995) Move methods that are for internal usage from CellUtil to Private util class
[ https://issues.apache.org/jira/browse/HBASE-18995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805505#comment-16805505 ] Sean Busbey commented on HBASE-18995: - closed jira issues don't see much monitoring. You should raise your question on dev@hbase. > Move methods that are for internal usage from CellUtil to Private util class > > > Key: HBASE-18995 > URL: https://issues.apache.org/jira/browse/HBASE-18995 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan >Priority: Critical > Fix For: 2.0.0-alpha-4, 2.0.0 > > Attachments: HBASE-18995-branch-2.002.patch, > HBASE-18995-branch-2.patch, HBASE-18995-branch-2_1.patch, > HBASE-18995-branch-2_1.patch, HBASE-18995-branch-2_1.patch, > HBASE-18995-branch-2_1.patch, HBASE-18995-branch-2_2.patch, > HBASE-18995_002-branch-2.patch, HBASE-18995_002-branch-2.patch, > HBASE-18995_003-branch-2.patch, HBASE-18995_1.patch, HBASE-18995_2.patch, > HBASE-18995_2.patch > > > This was brought up long time back. We need to move some of the public APIs > from CellUtil to internal private Util class because they are used in some > internal flow and does not make sense to have it in a @public exposed Util > class. > The topic again came in HBASE-18945 RB comments also. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21393) Add an API ScheduleSCP() to HBCK2
[ https://issues.apache.org/jira/browse/HBASE-21393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-21393: Parent Issue: HBASE-21745 (was: HBASE-19121) > Add an API ScheduleSCP() to HBCK2 > -- > > Key: HBASE-21393 > URL: https://issues.apache.org/jira/browse/HBASE-21393 > Project: HBase > Issue Type: Sub-task > Components: hbase-operator-tools, hbck2 >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: 0001-HBASE-21393-Add-an-API-ScheduleSCP-to-HBCK2.patch, > 0002-HBASE-21393-Add-an-API-ScheduleSCP-to-HBCK2.patch > > > Add the API of ScheduleSCP() to hbase-operator-tools so that operators can > schedule ServerCrashProcedures of specified regionservers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21262) [hbck2] AMv2 Lock Picker
[ https://issues.apache.org/jira/browse/HBASE-21262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-21262: Parent Issue: HBASE-21745 (was: HBASE-19121) > [hbck2] AMv2 Lock Picker > > > Key: HBASE-21262 > URL: https://issues.apache.org/jira/browse/HBASE-21262 > Project: HBase > Issue Type: Sub-task > Components: hbck2, Operability >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 3.0.0, 2.3.0 > > > This issue is about adding a lock picker to the HbckService > Over the w/e I had interesting case where an enable failed -- a subprocedure > ran into an exclusive lock (I think) -- and then the parent enabletabled > tried rollback. The rollback threw CODE-BUG because some subprocedures were > in unrollbackable states so we ended up skipping out of the enable table > procedure. The enable table procedure was marked ROLLBACKED... so it got > GC'd. But the exclusive lock it had on the table stayed in place. > The above has to be fixed but for the future, we need way to kill locks > otherwise only alternative if removing master proc wal files -- which is a > bigger pain restoring good state. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21966) Fix region holes, overlaps, and other region related errors
[
https://issues.apache.org/jira/browse/HBASE-21966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805548#comment-16805548
]
Sean Busbey commented on HBASE-21966:
-
Some notes from a discussion [~elserj] and I ended up having after a customer
escalation:
{quote}
We liked the idea
of making very focused operations, rather than sweeping "-repair"
options, e.g. "create a row in hbase:meta for this regiondir", "create
an empty regiondir", "create a regiondir from this hbase:meta row".
With tools like this, you could imagine a CLI tool stepping through
the Regions of a table presenting a three-way merge like tool: for
every region in a table, ask the user if they want to keep the state
in meta or the state in HDFS. We like this idea because it keeps HBase
devs out of the role of figuring out what the correct thing to do is.
A couple of related concerns:
* Such a tool would not aim to be sufficient for the bar some folks have
expressed for HBck2 to move the "stable" pointer to HBase 2. Essentially some
ability to rebuild meta from external info ala HBASE-21665 or HBASE-18840
* Need to make sure these tools are compose-able. It's all
well-and-good to say that human-insight needs to be applied to know
what HBCK2 commands to run, but we also don't want cluster recoveries
to take 10's of hours. Something easily scriptable is important. To continue
the three-way-merge analogy, merge strategies ala ours/theirs in git.
{quote}
> Fix region holes, overlaps, and other region related errors
> ---
>
> Key: HBASE-21966
> URL: https://issues.apache.org/jira/browse/HBASE-21966
> Project: HBase
> Issue Type: Sub-task
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19231) Redo TestMetaWithReplicas#testChangingReplicaCount; uses HBCK to validate
[ https://issues.apache.org/jira/browse/HBASE-19231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805551#comment-16805551 ] Sean Busbey commented on HBASE-19231: - What's still actionable here, if anything? Do we need better tests around edge cases with read replicas for meta? I'd like to move this out of being a subtask, but I'm not clear on what needs to happen for this to close. > Redo TestMetaWithReplicas#testChangingReplicaCount; uses HBCK to validate > - > > Key: HBASE-19231 > URL: https://issues.apache.org/jira/browse/HBASE-19231 > Project: HBase > Issue Type: Sub-task > Components: hbck >Reporter: stack >Assignee: stack >Priority: Major > > Also #testHBaseFsckWithFewerMetaReplicas, > #testHBaseFsckWithExcessMetaReplicas, and > #testHBaseFsckWithFewerMetaReplicaZnodes in TestMetaWithReplicas. Both depend > on HBCK for validation. Disabled for now. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805574#comment-16805574 ] Duo Zhang commented on HBASE-22130: --- [~stack] I think we'd better exclude several transitive dependencies from guava, as we did before. Let me polish the patch~ > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Attachments: > 0001-HBASE-22130-hbase-thirdparty-Upgrade-thirdparty-depe.patch > > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22130: -- Attachment: HBASE-22130.patch > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Attachments: > 0001-HBASE-22130-hbase-thirdparty-Upgrade-thirdparty-depe.patch, > HBASE-22130.patch > > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22130) [hbase-thirdparty] Upgrade thirdparty dependencies
[ https://issues.apache.org/jira/browse/HBASE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805581#comment-16805581 ] Duo Zhang commented on HBASE-22130: --- [~stack] PTAL sir. Thanks. > [hbase-thirdparty] Upgrade thirdparty dependencies > -- > > Key: HBASE-22130 > URL: https://issues.apache.org/jira/browse/HBASE-22130 > Project: HBase > Issue Type: Task > Components: thirdparty >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Attachments: > 0001-HBASE-22130-hbase-thirdparty-Upgrade-thirdparty-depe.patch, > HBASE-22130.patch > > > First guava has a CVE so we need to upgrade to at least 26.0, better to the > newest 27.1. > And we can also upgrade the other dependencies to the newest version at the > same time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang reopened HBASE-22073:
---
This breaks 2.2+, and there are no fix versions for 2.2+ but has committed to
branch-2.2+? Let me revert first...
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22133) Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+
Duo Zhang created HBASE-22133: - Summary: Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+ Key: HBASE-22133 URL: https://issues.apache.org/jira/browse/HBASE-22133 Project: HBase Issue Type: Bug Components: UI Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 3.0.0, 2.2.0, 2.3.0 The RIT procedure has been changed for branch-2.2+ so we can not use the patch for branch-2.1 directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-22073.
---
Resolution: Fixed
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22099) Backport HBASE-21895 "Error prone upgrade" to branch-2
[ https://issues.apache.org/jira/browse/HBASE-22099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22099: -- Attachment: HBASE-22099-branch-2.patch > Backport HBASE-21895 "Error prone upgrade" to branch-2 > -- > > Key: HBASE-22099 > URL: https://issues.apache.org/jira/browse/HBASE-22099 > Project: HBase > Issue Type: Task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.2.0, 2.3.0, 2.0.6, 2.1.5 > > Attachments: HBASE-22099-branch-2.patch, HBASE-22099-branch-2.patch, > HBASE-22099-branch-2.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22133) Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+
[ https://issues.apache.org/jira/browse/HBASE-22133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22133: -- Attachment: HBASE-22133.patch > Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to > branch-2.2+ > --- > > Key: HBASE-22133 > URL: https://issues.apache.org/jira/browse/HBASE-22133 > Project: HBase > Issue Type: Bug > Components: UI >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0 > > Attachments: HBASE-22133.patch > > > The RIT procedure has been changed for branch-2.2+ so we can not use the > patch for branch-2.1 directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22133) Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+
[ https://issues.apache.org/jira/browse/HBASE-22133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-22133: -- Status: Patch Available (was: Open) > Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to > branch-2.2+ > --- > > Key: HBASE-22133 > URL: https://issues.apache.org/jira/browse/HBASE-22133 > Project: HBase > Issue Type: Bug > Components: UI >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0 > > Attachments: HBASE-22133.patch > > > The RIT procedure has been changed for branch-2.2+ so we can not use the > patch for branch-2.1 directly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22005) Use ByteBuff's refcnt to track the life cycle of data block
[ https://issues.apache.org/jira/browse/HBASE-22005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805599#comment-16805599 ] Zheng Hu commented on HBASE-22005: -- bq. Can we change mob hfile to work like normal hfile? Yeah, Let me try to improve this in HBASE-22122. > Use ByteBuff's refcnt to track the life cycle of data block > --- > > Key: HBASE-22005 > URL: https://issues.apache.org/jira/browse/HBASE-22005 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-22005.HBASE-21879.v1.patch, > HBASE-22005.HBASE-21879.v2.patch, HBASE-22005.HBASE-21879.v3.patch, > HBASE-22005.HBASE-21879.v4.patch, HBASE-22005.HBASE-21879.v5.patch, > HBASE-22005.HBASE-21879.v6.patch, HBASE-22005.HBASE-21879.v7.patch, > HBASE-22005.HBASE-21879.v8.patch, HBASE-22005.HBASE-21879.v9.patch, > HBASE-22005.HBASE-21879.v9.patch, cell-encoding.jpeg > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22127) Introduce an switch to allow the LRUBlockCache offheap or not.
[ https://issues.apache.org/jira/browse/HBASE-22127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805600#comment-16805600 ] Zheng Hu commented on HBASE-22127: -- bq. by design, LRUBlockCache is on heap, so the correct way is to copy it on heap and then put it into LRUBlockCache. Yeah, you are right. but the problem is: when reading block based on (offset, len), we can not decide whether the block is an IndexBlock or DataBlock in advance, so can only allocate an ByteBuff with length size, then read the block and parse the block type, we know it's an indexBlock and put it into lruCache finally. Let me think about this. > Introduce an switch to allow the LRUBlockCache offheap or not. > -- > > Key: HBASE-22127 > URL: https://issues.apache.org/jira/browse/HBASE-22127 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > > In here [1], [~anoop.hbase] pointed out an crtial problem , I pasted here: > bq. So if we read from HDFS into a pooled BB and then give to LRU cache for > caching (ya mostly cache on read might be true) we will cache the block which > is backed by this pooled DBB? Unless the block is evicted , this BB wont go > back to pool. I think this is some thing we can not livw with !! For LRU > cache the sizing itself is based on what % of heap size we can grow. But here > in effect we are occupying the off heap space for the cached blocks. All the > sizing assumptions and calc going out of control ! > It's indeed an big problem here. so we can only make the block ref to an heap > area if we use LRUCache (both LruBlockCache and CombinedBlockCache case). Or > we can also make the lru cache offheap ? > I think we can introduce an switch indicate that whether the lru block cache > offheap or not, if heap, then coping those bytes from ByteBuff to heap. > https://reviews.apache.org/r/70153/diff/6?file=2133545#file2133545line398 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kevin su updated HBASE-22131: - Attachment: HBASE-22131.v0.patch Status: Patch Available (was: Open) > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > Attachments: HBASE-22131.v0.patch > > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[
https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805607#comment-16805607
]
Hadoop QA commented on HBASE-22131:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
35s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 10m 9s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22131 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964263/HBASE-22131.v0.patch |
| Optional Tests | dupname asflicense javac javadoc unit |
| uname | Linux 1246ec15bd2a 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 833736f28a |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/16591/testReport/ |
| Max. process+thread count | 97 (vs. ulimit of 1) |
| modules | C: hbase-protocol-shaded U: hbase-protocol-shaded |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16591/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Delete the patches in hbase-protocol-shaded module
> --
>
> Key: HBASE-22131
> URL: https://issues.apache.org/jira/browse/HBASE-22131
> Project: HBase
> Issue Type: Task
>Reporter: Duo Zhang
>Assignee: kevin su
>Priority: Major
> Attachments: HBASE-22131.v0.patch
>
>
> As now we will apply the patch in the hbase-thirdparty repo.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22127) Introduce an switch to allow the LRUBlockCache offheap or not.
[ https://issues.apache.org/jira/browse/HBASE-22127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805620#comment-16805620 ] Anoop Sam John commented on HBASE-22127: When we use off heap BC to store data blocks, read from HDFS using the pooled DBBs and then copy it to off heap BC is the best. Ya the issue is we dont know prior what type of block we are going to fetch. (Some way we can know?) bq. but IIRC, on heap is faster than off heap in the past, that why we put index in LRUBlockCache Ya seems true specially when we deal with smaller sized LRU cache. Again the difference also wont be that big. That is what our tests during HBASE-11425 shown. Anyway lets try to solve this issue here. > Introduce an switch to allow the LRUBlockCache offheap or not. > -- > > Key: HBASE-22127 > URL: https://issues.apache.org/jira/browse/HBASE-22127 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > > In here [1], [~anoop.hbase] pointed out an crtial problem , I pasted here: > bq. So if we read from HDFS into a pooled BB and then give to LRU cache for > caching (ya mostly cache on read might be true) we will cache the block which > is backed by this pooled DBB? Unless the block is evicted , this BB wont go > back to pool. I think this is some thing we can not livw with !! For LRU > cache the sizing itself is based on what % of heap size we can grow. But here > in effect we are occupying the off heap space for the cached blocks. All the > sizing assumptions and calc going out of control ! > It's indeed an big problem here. so we can only make the block ref to an heap > area if we use LRUCache (both LruBlockCache and CombinedBlockCache case). Or > we can also make the lru cache offheap ? > I think we can introduce an switch indicate that whether the lru block cache > offheap or not, if heap, then coping those bytes from ByteBuff to heap. > https://reviews.apache.org/r/70153/diff/6?file=2133545#file2133545line398 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22134) JIT deoptimization in Cell.write
Todd Lipcon created HBASE-22134: --- Summary: JIT deoptimization in Cell.write Key: HBASE-22134 URL: https://issues.apache.org/jira/browse/HBASE-22134 Project: HBase Issue Type: Bug Components: Performance Affects Versions: 2.0.2 Reporter: Todd Lipcon I was looking at a profile of a workload which was running compaction very slowly, and saw that the top CPU consumers were from JVM internals regarding deoptimization. I managed to write a little systemtap script to extract the deoptimization log and got the following in a tight loop: "Uncommon trap: trap_request=0xff67 fr.pc=0x7f85bcdb8644" "Uncommon trap: reason=unstable_if action=none pc=0x7f85bcdb8644 method=org.apache.hadoop.hbase.io.encoding.NoneEncoder.write(Lorg/apache/hadoop/hbase/Cell;)I @ 67" "DEOPT PACKING pc=0x7f85bcdb8644 sp=0x7f84d3d83080" "DEOPT UNPACKING pc=0x7f85b5005229 sp=0x7f84d3d82f30 mode 2" The java stack is spending most of its time at: java.lang.Thread.State: RUNNABLE at org.apache.hadoop.hbase.io.encoding.NoneEncoder.write(NoneEncoder.java:57) at org.apache.hadoop.hbase.io.hfile.NoOpDataBlockEncoder.encode(NoOpDataBlockEncoder.java:55) at org.apache.hadoop.hbase.io.hfile.HFileBlock$Writer.write(HFileBlock.java:983) at org.apache.hadoop.hbase.io.hfile.HFileWriterImpl.append(HFileWriterImpl.java:740) This was with Oracle JDK 1.8.0_112. Likely a JDK bug but perhaps some reorganization of this code path could help avoid triggering the bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22134) JIT deoptimization in Cell.write
[
https://issues.apache.org/jira/browse/HBASE-22134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805632#comment-16805632
]
Todd Lipcon commented on HBASE-22134:
-
For future reference, the stap script I used was:
{code}
probe process("/usr/lib64/libc-2.17.so").function("_IO_vsnprintf").return {
printf("%s\n", user_string_n_quoted(@entry($string), $return));
}
{code}
(because I noticed that there was a call to vsnprintf in the deoptimization
path, I guessed it was log-message-related, and bingo!). Likely you could get
the same info out of LogCompilation but that flag can't be switched at runtime.
> JIT deoptimization in Cell.write
>
>
> Key: HBASE-22134
> URL: https://issues.apache.org/jira/browse/HBASE-22134
> Project: HBase
> Issue Type: Bug
> Components: Performance
>Affects Versions: 2.0.2
>Reporter: Todd Lipcon
>Priority: Major
>
> I was looking at a profile of a workload which was running compaction very
> slowly, and saw that the top CPU consumers were from JVM internals regarding
> deoptimization. I managed to write a little systemtap script to extract the
> deoptimization log and got the following in a tight loop:
> "Uncommon trap: trap_request=0xff67 fr.pc=0x7f85bcdb8644"
> "Uncommon trap: reason=unstable_if action=none pc=0x7f85bcdb8644
> method=org.apache.hadoop.hbase.io.encoding.NoneEncoder.write(Lorg/apache/hadoop/hbase/Cell;)I
> @ 67"
> "DEOPT PACKING pc=0x7f85bcdb8644 sp=0x7f84d3d83080"
> "DEOPT UNPACKING pc=0x7f85b5005229 sp=0x7f84d3d82f30 mode 2"
> The java stack is spending most of its time at:
> java.lang.Thread.State: RUNNABLE
> at
> org.apache.hadoop.hbase.io.encoding.NoneEncoder.write(NoneEncoder.java:57)
> at
> org.apache.hadoop.hbase.io.hfile.NoOpDataBlockEncoder.encode(NoOpDataBlockEncoder.java:55)
> at
> org.apache.hadoop.hbase.io.hfile.HFileBlock$Writer.write(HFileBlock.java:983)
> at
> org.apache.hadoop.hbase.io.hfile.HFileWriterImpl.append(HFileWriterImpl.java:740)
> This was with Oracle JDK 1.8.0_112. Likely a JDK bug but perhaps some
> reorganization of this code path could help avoid triggering the bug.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22134) JIT deoptimization in Cell.write
[ https://issues.apache.org/jira/browse/HBASE-22134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805633#comment-16805633 ] Todd Lipcon commented on HBASE-22134: - Looks a lot like what's reported here: http://openjdk.5641.n7.nabble.com/Deoptimization-taking-up-most-CPU-cycles-td274012.html > JIT deoptimization in Cell.write > > > Key: HBASE-22134 > URL: https://issues.apache.org/jira/browse/HBASE-22134 > Project: HBase > Issue Type: Bug > Components: Performance >Affects Versions: 2.0.2 >Reporter: Todd Lipcon >Priority: Major > > I was looking at a profile of a workload which was running compaction very > slowly, and saw that the top CPU consumers were from JVM internals regarding > deoptimization. I managed to write a little systemtap script to extract the > deoptimization log and got the following in a tight loop: > "Uncommon trap: trap_request=0xff67 fr.pc=0x7f85bcdb8644" > "Uncommon trap: reason=unstable_if action=none pc=0x7f85bcdb8644 > method=org.apache.hadoop.hbase.io.encoding.NoneEncoder.write(Lorg/apache/hadoop/hbase/Cell;)I > @ 67" > "DEOPT PACKING pc=0x7f85bcdb8644 sp=0x7f84d3d83080" > "DEOPT UNPACKING pc=0x7f85b5005229 sp=0x7f84d3d82f30 mode 2" > The java stack is spending most of its time at: > java.lang.Thread.State: RUNNABLE > at > org.apache.hadoop.hbase.io.encoding.NoneEncoder.write(NoneEncoder.java:57) > at > org.apache.hadoop.hbase.io.hfile.NoOpDataBlockEncoder.encode(NoOpDataBlockEncoder.java:55) > at > org.apache.hadoop.hbase.io.hfile.HFileBlock$Writer.write(HFileBlock.java:983) > at > org.apache.hadoop.hbase.io.hfile.HFileWriterImpl.append(HFileWriterImpl.java:740) > This was with Oracle JDK 1.8.0_112. Likely a JDK bug but perhaps some > reorganization of this code path could help avoid triggering the bug. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22099) Backport HBASE-21895 "Error prone upgrade" to branch-2
[
https://issues.apache.org/jira/browse/HBASE-22099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805650#comment-16805650
]
Hadoop QA commented on HBASE-22099:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
23s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
51s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
24s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
4s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-build-support . hbase-build-configuration {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
58s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
4s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m
14s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 10m 14s{color}
| {color:red} root generated 1347 new + 20 unchanged - 1052 fixed = 1367 total
(was 1072) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
7s{color} | {color:green} The patch passed checkstyle in
hbase-build-configuration {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s{color} | {color:green} The patch passed checkstyle in hbase-protocol-shaded
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} hbase-procedure: The patch generated 0 new + 3
unchanged - 1 fixed = 3 total (was 4) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} The patch passed checkstyle in hbase-server {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s{color} | {color:green} hbase-mapreduce: The patch generated 0 new + 0
unchanged - 1 fixed = 0 total (was 1) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
6s{color} | {color:green} root: The patch generated 0 new + 40 unchanged - 2
fixed = 40 total (was 42) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
4s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
5s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 31s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-build-configuration . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
6s{color} | {color:green}
[jira] [Commented] (HBASE-22133) Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to branch-2.2+
[
https://issues.apache.org/jira/browse/HBASE-22133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805653#comment-16805653
]
Hadoop QA commented on HBASE-22133:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
48s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
1s{color} | {color:red} The patch 1 line(s) with tabs. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}244m 36s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}254m 42s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestAssignmentManagerMetrics |
| | hadoop.hbase.client.TestAdmin1 |
| | hadoop.hbase.client.TestFromClientSide |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-22133 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12964262/HBASE-22133.patch |
| Optional Tests | dupname asflicense javac javadoc unit |
| uname | Linux e1a0e08e6238 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 833736f28a |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| whitespace |
https://builds.apache.org/job/PreCommit-HBASE-Build/16590/artifact/patchprocess/whitespace-tabs.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/16590/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/16590/testReport/ |
| Max. process+thread count | 5475 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/16590/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Forward port HBASE-22073 "/rits.jsp throws an exception if no procedure" to
> branch-2.2+
> ---
>
> Key: HBASE-22133
> URL: https://issues.apache.org/jira/browse/HBASE-22133
> Project: HBase
> Issue Type: Bug
> Components: UI
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-22133.patch
>
>
> The RIT procedure has been changed for branch-2.2+ so we can not use the
> patch for branch-2.1 directly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22115) HBase RPC aspires to grow an infinite tree of trace scopes; some other places are also unsafe
[
https://issues.apache.org/jira/browse/HBASE-22115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805655#comment-16805655
]
Hudson commented on HBASE-22115:
Results for branch master
[build #896 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/896/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/896//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/896//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/896//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> HBase RPC aspires to grow an infinite tree of trace scopes; some other places
> are also unsafe
> -
>
> Key: HBASE-22115
> URL: https://issues.apache.org/jira/browse/HBASE-22115
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
> Attachments: Clipboard01.jpg, HBASE-22115.01.patch,
> HBASE-22115.02.patch, HBASE-22115.patch
>
>
> !Clipboard01.jpg!
> All of those are ClientServices.Multi in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805654#comment-16805654
]
Hudson commented on HBASE-22073:
Results for branch master
[build #896 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/896/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/896//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/896//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/896//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22115) HBase RPC aspires to grow an infinite tree of trace scopes; some other places are also unsafe
[
https://issues.apache.org/jira/browse/HBASE-22115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805656#comment-16805656
]
Hudson commented on HBASE-22115:
Results for branch branch-2
[build #1786 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> HBase RPC aspires to grow an infinite tree of trace scopes; some other places
> are also unsafe
> -
>
> Key: HBASE-22115
> URL: https://issues.apache.org/jira/browse/HBASE-22115
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Fix For: 3.0.0, 2.3.0, 2.2.1
>
> Attachments: Clipboard01.jpg, HBASE-22115.01.patch,
> HBASE-22115.02.patch, HBASE-22115.patch
>
>
> !Clipboard01.jpg!
> All of those are ClientServices.Multi in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22073) /rits.jsp throws an exception if no procedure
[
https://issues.apache.org/jira/browse/HBASE-22073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805658#comment-16805658
]
Hudson commented on HBASE-22073:
Results for branch branch-2
[build #1786 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1786//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> /rits.jsp throws an exception if no procedure
> -
>
> Key: HBASE-22073
> URL: https://issues.apache.org/jira/browse/HBASE-22073
> Project: HBase
> Issue Type: Bug
> Components: UI
>Affects Versions: 2.1.0
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.1.5
>
> Attachments: HBASE-22073.branch-2.1.patch, HBASE-22073.master.patch
>
>
> I got the following exception in our test environment:
> {noformat}
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.generated.master.rits_jsp._jspService(rits_jsp.java:101)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> ...
> {noformat}
> Because {{regionStateNode.getProcedure()}} returns {{null}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22099) Backport HBASE-21895 "Error prone upgrade" to branch-2
[ https://issues.apache.org/jira/browse/HBASE-22099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805661#comment-16805661 ] Duo Zhang commented on HBASE-22099: --- Let me commit. Thanks [~stack] for reviewing. > Backport HBASE-21895 "Error prone upgrade" to branch-2 > -- > > Key: HBASE-22099 > URL: https://issues.apache.org/jira/browse/HBASE-22099 > Project: HBase > Issue Type: Task > Components: build >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 2.2.0, 2.3.0, 2.0.6, 2.1.5 > > Attachments: HBASE-22099-branch-2.patch, HBASE-22099-branch-2.patch, > HBASE-22099-branch-2.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22131) Delete the patches in hbase-protocol-shaded module
[ https://issues.apache.org/jira/browse/HBASE-22131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805670#comment-16805670 ] Duo Zhang commented on HBASE-22131: --- +1. > Delete the patches in hbase-protocol-shaded module > -- > > Key: HBASE-22131 > URL: https://issues.apache.org/jira/browse/HBASE-22131 > Project: HBase > Issue Type: Task >Reporter: Duo Zhang >Assignee: kevin su >Priority: Major > Attachments: HBASE-22131.v0.patch > > > As now we will apply the patch in the hbase-thirdparty repo. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22121) AsyncAdmin can not deal with non default meta replica
[ https://issues.apache.org/jira/browse/HBASE-22121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805677#comment-16805677 ] Guanghao Zhang commented on HBASE-22121: Why don't move the new logic into AsyncMetaTableAccessor? > AsyncAdmin can not deal with non default meta replica > - > > Key: HBASE-22121 > URL: https://issues.apache.org/jira/browse/HBASE-22121 > Project: HBase > Issue Type: Bug > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.5 > > Attachments: HBASE-22121.patch, HBASE-22121.patch > > > In AsyncAdmin we support passing both encodedRegionName and regionName as a > parameter so we have a getRegionInfo method to get the RegionInfo first. > In general we will scan the meta table to get the region info, but for meta > region itself, the problem is that, we only check for the first replica, so > for the non default replicas, we will still go to the meta region and then > get an UnknownRegionException. > We should find a way to deal with this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22121) AsyncAdmin can not deal with non default meta replica
[ https://issues.apache.org/jira/browse/HBASE-22121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805678#comment-16805678 ] Duo Zhang commented on HBASE-22121: --- Because it is for locating meta region itself, not accessing meta? > AsyncAdmin can not deal with non default meta replica > - > > Key: HBASE-22121 > URL: https://issues.apache.org/jira/browse/HBASE-22121 > Project: HBase > Issue Type: Bug > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.5 > > Attachments: HBASE-22121.patch, HBASE-22121.patch > > > In AsyncAdmin we support passing both encodedRegionName and regionName as a > parameter so we have a getRegionInfo method to get the RegionInfo first. > In general we will scan the meta table to get the region info, but for meta > region itself, the problem is that, we only check for the first replica, so > for the non default replicas, we will still go to the meta region and then > get an UnknownRegionException. > We should find a way to deal with this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
