[jira] [Updated] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-20488: -- Description: The PerfomanceEvaluation tool currently prints its full path in help message instead of short name. (was: The PerfomanceEvaluation tool prints its full path in help message instead of short name.) > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Priority: Minor > Labels: beginner > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475377#comment-16475377 ] Peter Somogyi commented on HBASE-20488: --- Thanks for checking. This issue is about to replace the full name to the short one. Also 'java' needs to be replaced to 'hbase' "Usage: hbase pe [-D]* " > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Priority: Minor > Labels: beginner > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20576) Check remote WAL directory when creating peer and transiting peer to A
[ https://issues.apache.org/jira/browse/HBASE-20576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20576: -- Attachment: HBASE-20576-HBASE-19064-v2.patch > Check remote WAL directory when creating peer and transiting peer to A > -- > > Key: HBASE-20576 > URL: https://issues.apache.org/jira/browse/HBASE-20576 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v1.patch, HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v2.patch, HBASE-20576-HBASE-19064.patch, > HBASE-20576-HBASE-19064.patch > > > When testing on the real cluster I typed a wrong remote wal directory. Then I > start the procedure for transiting the peer to A, the procedure was stuck > there for ever... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475398#comment-16475398
]
Hadoop QA commented on HBASE-20444:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 3m
42s{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} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
18s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
25s{color} | {color:red} hbase-common: The patch generated 5 new + 1 unchanged
- 0 fixed = 6 total (was 1) {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
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}
17m 38s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
51s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 51m 6s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20444 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923418/HBASE-20444.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b9cfd065fb7a 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10
14:24:03 UTC 2017 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 / d2daada970 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12821/artifact/patchprocess/diff-checkstyle-hbase-common.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12821/testReport/ |
| Max. process+thread count | 302 (vs. ulimit of 1) |
| modules | C: hbase-common U: hbase-common |
| Console output |
ht
[jira] [Commented] (HBASE-20576) Check remote WAL directory when creating peer and transiting peer to A
[ https://issues.apache.org/jira/browse/HBASE-20576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475479#comment-16475479 ] Zheng Hu commented on HBASE-20576: -- LGTM for patch.v2, +1 if hadoop QA says OK. > Check remote WAL directory when creating peer and transiting peer to A > -- > > Key: HBASE-20576 > URL: https://issues.apache.org/jira/browse/HBASE-20576 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v1.patch, HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v2.patch, HBASE-20576-HBASE-19064.patch, > HBASE-20576-HBASE-19064.patch > > > When testing on the real cluster I typed a wrong remote wal directory. Then I > start the procedure for transiting the peer to A, the procedure was stuck > there for ever... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20581) HBase book documentation wrong for REST operations on schema endpoints
[
https://issues.apache.org/jira/browse/HBASE-20581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475481#comment-16475481
]
Balazs Meszaros commented on HBASE-20581:
-
+1 ship it!
> HBase book documentation wrong for REST operations on schema endpoints
> --
>
> Key: HBASE-20581
> URL: https://issues.apache.org/jira/browse/HBASE-20581
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Kevin Risden
>Assignee: Josh Elser
>Priority: Critical
> Attachments: HBASE-20581.001.patch
>
>
> On [https://hbase.apache.org/book.html#_using_rest_endpoints]
> The documentation states that to update a table schema (the configuration for
> a column family), the {{PUT}} HTTP verb will update the current configuration
> with the "fragment" of configuration provided, while the {{POST}} HTTP verb
> will replace the current configuration with whatever is provided.
> In reality, the opposite is true: {{POST}} updates the configuration, {{PUT}}
> replaces. The old javadoc for the o.a.h.h.rest package got it right, but the
> entry on the HBase book transposed this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-7303) Quit using reflection for the method DFSOutputStream#getNumCurrentReplicas(…)
[ https://issues.apache.org/jira/browse/HBASE-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harsh J reassigned HBASE-7303: -- Assignee: (was: Harsh J) > Quit using reflection for the method DFSOutputStream#getNumCurrentReplicas(…) > - > > Key: HBASE-7303 > URL: https://issues.apache.org/jira/browse/HBASE-7303 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.95.2 >Reporter: Harsh J >Priority: Minor > > Given that we've raised our minimum version guarantee for HBase with 1.x > carrying the 0.20-append code finally, and all subsequent releases (0.21*, > 0.22, 0.23 and 2) have this method available in them, I don't see a reason to > have the reflection based getNumCurrentReplicas invocation (via HDFS-826) > anymore. > We could save ourselves quite a bit of perf. penalty by removing this check > and simply calling the method directly, as its API has not changed across > releases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
maoling updated HBASE-20444:
Attachment: HBASE-20444.master.003.patch
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Assignee: maoling
>Priority: Major
> Attachments: HBASE-20444.master.001.patch,
> HBASE-20444.master.002.patch, HBASE-20444.master.003.patch
>
>
> As [~busbey] commented on HBASE-18792, current logic for comparing version
> strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and
> needs to be improved:
> {code:java}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> {quote}I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> {quote}
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> {quote}Can we expand the versions checked in TestVersionInfo to include a)
> some "same major different minor", b) "same minor different maintenance", c)
> both of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20578) Support region server group in target cluster
[ https://issues.apache.org/jira/browse/HBASE-20578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20578: --- Issue Type: Improvement (was: Sub-task) Parent: (was: HBASE-17362) > Support region server group in target cluster > - > > Key: HBASE-20578 > URL: https://issues.apache.org/jira/browse/HBASE-20578 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Albert Lee >Priority: Major > > When source tables belong to non-default region server group(s) and there are > region server group counterpart in the target cluster, we should support > replicating to target cluster using the region server group mapping. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20571) JMXJsonServlet generates invalid JSON if it has NaN in metrics
[
https://issues.apache.org/jira/browse/HBASE-20571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475520#comment-16475520
]
Hadoop QA commented on HBASE-20571:
---
| (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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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} branch-2.0 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
35s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
47s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
23s{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
20s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{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} 4m
29s{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 26s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}117m
42s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}158m 34s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:369877d |
| JIRA Issue | HBASE-20571 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923417/HBASE-20571.branch-2.0.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 667fc1c0a6ad 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 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.0 / f0c8904efe |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12820/testReport/ |
| Max. process+thread count | 4036 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/
[jira] [Commented] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475559#comment-16475559
]
Hadoop QA commented on HBASE-20444:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
14s{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} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
14s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{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} 4m
14s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
13m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
33s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m 43s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20444 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923443/HBASE-20444.master.003.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 335e56aaad4d 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / d2daada970 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12823/testReport/ |
| Max. process+thread count | 286 (vs. ulimit of 1) |
| modules | C: hbase-common U: hbase-common |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12823/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Improve vers
[jira] [Comment Edited] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16474224#comment-16474224
]
maoling edited comment on HBASE-20444 at 5/15/18 9:44 AM:
--
1.
{code:java}
"0.98.11", "0.99.11", "0.99.14", "1.99.14", "2.0.0-alpha-1", "2.0.0-alpha-3",
"2.0.0-beta-3", "2.0.0-SNAPSHOT", "2.0", "2.0.0.1", "2.0.1"
{code}
"*2.0.0-patch-123*" isn't taken into consideration in the patch
2.*assertTrue(VersionInfo.compareVersion("2.0.0", "2.0.0-SNAPSHOT") < 0)* is a
wrong UT.
3.commons-lang's *StringUtils#isNumeric* cannot pass checkstyle due to
*checkstyle.xml*
{code:java}
{code}
was (Author: maoling):
1.
{code:java}
"0.98.11", "0.99.11", "0.99.14", "1.99.14", "2.0.0-alpha-1", "2.0.0-alpha-3",
"2.0.0-beta-3", "2.0.0-SNAPSHOT", "2.0", "2.0.0.1", "2.0.1"
{code}
"2.0.0-patch-123" isn't taken into consideration in the patch
2.assertTrue(VersionInfo.compareVersion("2.0.0", "2.0.0-SNAPSHOT") < 0) is a
wrong UT.
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Assignee: maoling
>Priority: Major
> Attachments: HBASE-20444.master.001.patch,
> HBASE-20444.master.002.patch, HBASE-20444.master.003.patch
>
>
> As [~busbey] commented on HBASE-18792, current logic for comparing version
> strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and
> needs to be improved:
> {code:java}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> {quote}I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> {quote}
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> {quote}Can we expand the versions checked in TestVersionInfo to include a)
> some "same major different minor", b) "same minor different maintenance", c)
> both of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20576) Check remote WAL directory when creating peer and transiting peer to A
[
https://issues.apache.org/jira/browse/HBASE-20576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475569#comment-16475569
]
Hadoop QA commented on HBASE-20576:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
21s{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} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
56s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
43s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
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} 2m
3s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
9s{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} 4m
51s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
14m 43s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
7s{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:green}+1{color} | {color:green} unit {color} | {color:green}105m
28s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}153m 30s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20576 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923425/HBASE-20576-HBASE-19064-v2.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 45e189aa8bcd 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 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 | HBASE-19064 / 774e6b6c7f |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12822/testReport/ |
| Max. process+thread count | 4219 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12822/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was
[jira] [Created] (HBASE-20584) TestRestoreSnapshotFromClient failed
Jingyun Tian created HBASE-20584:
Summary: TestRestoreSnapshotFromClient failed
Key: HBASE-20584
URL: https://issues.apache.org/jira/browse/HBASE-20584
Project: HBase
Issue Type: Bug
Affects Versions: 3.0.0
Reporter: Jingyun Tian
Assignee: Jingyun Tian
org.apache.hadoop.hbase.snapshot.HBaseSnapshotException:
org.apache.hadoop.hbase.snapshot.HBaseSnapshotException: Snapshot {
ss=snaptb1-1526376636687
table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH } had
an error. Procedure snaptb1-1526376636687 { waiting=[] done=[] }
at
org.apache.hadoop.hbase.master.snapshot.SnapshotManager.isSnapshotDone(SnapshotManager.java:380)
at
org.apache.hadoop.hbase.master.MasterRpcServices.isSnapshotDone(MasterRpcServices.java:1128)
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)
Caused by: org.apache.hadoop.hbase.snapshot.CorruptedSnapshotException via
Failed taking snapshot { ss=snaptb1-1526376636687
table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH } due
to exception:Regions moved during the snapshot '{ ss=snaptb1-1526376636687
table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH }'.
expected=6
snapshotted=7.:org.apache.hadoop.hbase.snapshot.CorruptedSnapshotException:
Regions moved during the snapshot '{ ss=snaptb1-1526376636687
table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH }'.
expected=6 snapshotted=7.
at
org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher.rethrowException(ForeignExceptionDispatcher.java:82)
at
org.apache.hadoop.hbase.master.snapshot.TakeSnapshotHandler.rethrowExceptionIfFailed(TakeSnapshotHandler.java:311)
at
org.apache.hadoop.hbase.master.snapshot.SnapshotManager.isSnapshotDone(SnapshotManager.java:369)
... 6 more
Caused by: org.apache.hadoop.hbase.snapshot.CorruptedSnapshotException: Regions
moved during the snapshot '{ ss=snaptb1-1526376636687
table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH }'.
expected=6 snapshotted=7.
at
org.apache.hadoop.hbase.master.snapshot.MasterSnapshotVerifier.verifyRegions(MasterSnapshotVerifier.java:217)
at
org.apache.hadoop.hbase.master.snapshot.MasterSnapshotVerifier.verifySnapshot(MasterSnapshotVerifier.java:121)
at
org.apache.hadoop.hbase.master.snapshot.TakeSnapshotHandler.process(TakeSnapshotHandler.java:207)
at
org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:748)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:100)
at
org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteException(RemoteWithExtrasException.java:90)
at
org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.makeIOExceptionOfException(ProtobufUtil.java:360)
at
org.apache.hadoop.hbase.shaded.protobuf.ProtobufUtil.handleRemoteException(ProtobufUtil.java:348)
at
org.apache.hadoop.hbase.client.MasterCallable.call(MasterCallable.java:101)
at
org.apache.hadoop.hbase.client.RpcRetryingCallerImpl.callWithRetries(RpcRetryingCallerImpl.java:107)
at
org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:3061)
at
org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:3053)
at
org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:2532)
at
org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:2499)
at
org.apache.hadoop.hbase.client.HBaseAdmin.snapshot(HBaseAdmin.java:2492)
at
org.apache.hadoop.hbase.client.TestRestoreSnapshotFromClient.testRestoreSnapshotAfterSplittingRegions(TestRestoreSnapshotFromClient.java:311)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.refl
[jira] [Commented] (HBASE-20576) Check remote WAL directory when creating peer and transiting peer to A
[ https://issues.apache.org/jira/browse/HBASE-20576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475639#comment-16475639 ] Duo Zhang commented on HBASE-20576: --- Let me commit. > Check remote WAL directory when creating peer and transiting peer to A > -- > > Key: HBASE-20576 > URL: https://issues.apache.org/jira/browse/HBASE-20576 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v1.patch, HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v2.patch, HBASE-20576-HBASE-19064.patch, > HBASE-20576-HBASE-19064.patch > > > When testing on the real cluster I typed a wrong remote wal directory. Then I > start the procedure for transiting the peer to A, the procedure was stuck > there for ever... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20576) Check remote WAL directory when creating peer and transiting peer to A
[ https://issues.apache.org/jira/browse/HBASE-20576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20576: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch HBASE-19064. Thanks [~openinx] for reviewing. > Check remote WAL directory when creating peer and transiting peer to A > -- > > Key: HBASE-20576 > URL: https://issues.apache.org/jira/browse/HBASE-20576 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-19064 > > Attachments: HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v1.patch, HBASE-20576-HBASE-19064-v1.patch, > HBASE-20576-HBASE-19064-v2.patch, HBASE-20576-HBASE-19064.patch, > HBASE-20576-HBASE-19064.patch > > > When testing on the real cluster I typed a wrong remote wal directory. Then I > start the procedure for transiting the peer to A, the procedure was stuck > there for ever... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[
https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475653#comment-16475653
]
Hudson commented on HBASE-20447:
Results for branch branch-1
[build #315 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/315/]:
(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-1/315//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/315//JDK7_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-1/315//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Only fail cacheBlock if block collisions aren't related to next block metadata
> --
>
> Key: HBASE-20447
> URL: https://issues.apache.org/jira/browse/HBASE-20447
> Project: HBase
> Issue Type: Bug
> Components: BlockCache, BucketCache
>Affects Versions: 1.4.3, 2.0.0
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.4.5
>
> Attachments: HBASE-20447.branch-1.001.patch,
> HBASE-20447.branch-1.002.patch, HBASE-20447.branch-1.003.patch,
> HBASE-20447.branch-1.004.patch, HBASE-20447.branch-1.005.patch,
> HBASE-20447.branch-1.006.patch, HBASE-20447.master.001.patch,
> HBASE-20447.master.002.patch, HBASE-20447.master.003.patch,
> HBASE-20447.master.004.patch
>
>
> This is the issue I was originally having here:
> [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E]
>
> When we pread, we don't force the read to read all of the next block header.
> However, when we get into a race condition where two opener threads try to
> cache the same block and one thread read all of the next block header and the
> other one didn't, it will fail the open process. This is especially important
> in a splitting case where it will potentially fail the split process.
> Instead, in the caches, we should only fail if the required blocks are
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20569) NPE in RecoverStandbyProcedure.execute
[ https://issues.apache.org/jira/browse/HBASE-20569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-20569: --- Attachment: HBASE-20569.HBASE-19064.002.patch > NPE in RecoverStandbyProcedure.execute > -- > > Key: HBASE-20569 > URL: https://issues.apache.org/jira/browse/HBASE-20569 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20569.HBASE-19064.001.patch, > HBASE-20569.HBASE-19064.002.patch > > > We call ReplaySyncReplicationWALManager.initPeerWorkers in INIT_WORKERS state > and then use it in DISPATCH_TASKS. But if we restart the master and the > procedure is restarted from state DISPATCH_TASKS, no one will call the > initPeerWorkers method and we will get NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20569) NPE in RecoverStandbyProcedure.execute
[ https://issues.apache.org/jira/browse/HBASE-20569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475711#comment-16475711 ] Guanghao Zhang commented on HBASE-20569: Add a 002 patch which add a new ut. But the standby master still have problem when become active master. Now it will failed when recover meta... The log shows that it will kill other RS when recover meta... Need dig more. > NPE in RecoverStandbyProcedure.execute > -- > > Key: HBASE-20569 > URL: https://issues.apache.org/jira/browse/HBASE-20569 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-20569.HBASE-19064.001.patch, > HBASE-20569.HBASE-19064.002.patch > > > We call ReplaySyncReplicationWALManager.initPeerWorkers in INIT_WORKERS state > and then use it in DISPATCH_TASKS. But if we restart the master and the > procedure is restarted from state DISPATCH_TASKS, no one will call the > initPeerWorkers method and we will get NPE. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20584) TestRestoreSnapshotFromClient failed
[
https://issues.apache.org/jira/browse/HBASE-20584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475759#comment-16475759
]
Jingyun Tian commented on HBASE-20584:
--
The problem is at CellComparatorImpl,
{code}
public final int compare(final Cell a, final Cell b, boolean ignoreSequenceid) {
int diff = 0;
if (a instanceof ByteBufferKeyValue && b instanceof ByteBufferKeyValue) {
diff = compareByteBufferKeyValue((ByteBufferKeyValue)a, (ByteBufferKeyValue)b);
if (diff != 0) {
return diff;
}
} else {
diff = compareRows(a, b);
if (diff != 0) {
return diff;
}
diff = compareWithoutRow(a, b);
if (diff != 0) {
return diff;
}
}
// Negate following comparisons so later edits show up first mvccVersion:
later sorts first
return ignoreSequenceid? diff: Longs.compare(b.getSequenceId(),
a.getSequenceId());
}
{code}
Removed compareByteBufferKeyValue related code then the test can pass.
Seems this method return wrong result when compare rows in meta table.
Can you check this out? [~stack]
> TestRestoreSnapshotFromClient failed
>
>
> Key: HBASE-20584
> URL: https://issues.apache.org/jira/browse/HBASE-20584
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Major
>
> org.apache.hadoop.hbase.snapshot.HBaseSnapshotException:
> org.apache.hadoop.hbase.snapshot.HBaseSnapshotException: Snapshot {
> ss=snaptb1-1526376636687
> table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH } had
> an error. Procedure snaptb1-1526376636687 { waiting=[] done=[] }
> at
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager.isSnapshotDone(SnapshotManager.java:380)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.isSnapshotDone(MasterRpcServices.java:1128)
> 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)
> Caused by: org.apache.hadoop.hbase.snapshot.CorruptedSnapshotException via
> Failed taking snapshot { ss=snaptb1-1526376636687
> table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH } due
> to exception:Regions moved during the snapshot '{ ss=snaptb1-1526376636687
> table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH }'.
> expected=6
> snapshotted=7.:org.apache.hadoop.hbase.snapshot.CorruptedSnapshotException:
> Regions moved during the snapshot '{ ss=snaptb1-1526376636687
> table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH }'.
> expected=6 snapshotted=7.
> at
> org.apache.hadoop.hbase.errorhandling.ForeignExceptionDispatcher.rethrowException(ForeignExceptionDispatcher.java:82)
> at
> org.apache.hadoop.hbase.master.snapshot.TakeSnapshotHandler.rethrowExceptionIfFailed(TakeSnapshotHandler.java:311)
> at
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager.isSnapshotDone(SnapshotManager.java:369)
> ... 6 more
> Caused by: org.apache.hadoop.hbase.snapshot.CorruptedSnapshotException:
> Regions moved during the snapshot '{ ss=snaptb1-1526376636687
> table=testRestoreSnapshotAfterSplittingRegions-1526376636687 type=FLUSH }'.
> expected=6 snapshotted=7.
> at
> org.apache.hadoop.hbase.master.snapshot.MasterSnapshotVerifier.verifyRegions(MasterSnapshotVerifier.java:217)
> at
> org.apache.hadoop.hbase.master.snapshot.MasterSnapshotVerifier.verifySnapshot(MasterSnapshotVerifier.java:121)
> at
> org.apache.hadoop.hbase.master.snapshot.TakeSnapshotHandler.process(TakeSnapshotHandler.java:207)
> at
> org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:100)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteE
[jira] [Commented] (HBASE-20560) Revisit the TestReplicationDroppedTables ut
[
https://issues.apache.org/jira/browse/HBASE-20560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475772#comment-16475772
]
Hudson commented on HBASE-20560:
Results for branch master
[build #331 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/331/]: (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/331//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/331//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/331//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Revisit the TestReplicationDroppedTables ut
> ---
>
> Key: HBASE-20560
> URL: https://issues.apache.org/jira/browse/HBASE-20560
> Project: HBase
> Issue Type: Bug
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Attachments: HBASE-20560.patch, HBASE-20560.patch
>
>
> After HBASE-20475, the ut TestReplicationDroppedTables has been more stable
> now, but still failed in few times..
> Checked the code again, I found the problems:
> 1.
> https://issues.apache.org/jira/browse/HBASE-20475?focusedCommentId=16465759&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16465759
> 2.
> https://issues.apache.org/jira/browse/HBASE-20475?focusedCommentId=16467225&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16467225
> So prepared a patch for the revisiting..
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[
https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475775#comment-16475775
]
Hudson commented on HBASE-20447:
Results for branch master
[build #331 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/331/]: (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/331//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/331//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/331//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Only fail cacheBlock if block collisions aren't related to next block metadata
> --
>
> Key: HBASE-20447
> URL: https://issues.apache.org/jira/browse/HBASE-20447
> Project: HBase
> Issue Type: Bug
> Components: BlockCache, BucketCache
>Affects Versions: 1.4.3, 2.0.0
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.4.5
>
> Attachments: HBASE-20447.branch-1.001.patch,
> HBASE-20447.branch-1.002.patch, HBASE-20447.branch-1.003.patch,
> HBASE-20447.branch-1.004.patch, HBASE-20447.branch-1.005.patch,
> HBASE-20447.branch-1.006.patch, HBASE-20447.master.001.patch,
> HBASE-20447.master.002.patch, HBASE-20447.master.003.patch,
> HBASE-20447.master.004.patch
>
>
> This is the issue I was originally having here:
> [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E]
>
> When we pread, we don't force the read to read all of the next block header.
> However, when we get into a race condition where two opener threads try to
> cache the same block and one thread read all of the next block header and the
> other one didn't, it will fail the open process. This is especially important
> in a splitting case where it will potentially fail the split process.
> Instead, in the caches, we should only fail if the required blocks are
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20544) downstream HBaseTestingUtility fails with invalid port
[
https://issues.apache.org/jira/browse/HBASE-20544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475774#comment-16475774
]
Hudson commented on HBASE-20544:
Results for branch master
[build #331 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/331/]: (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/331//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/331//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/331//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> downstream HBaseTestingUtility fails with invalid port
> --
>
> Key: HBASE-20544
> URL: https://issues.apache.org/jira/browse/HBASE-20544
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 3.0.0, 2.1.0, 2.0.1
>
> Attachments: HBASE-20544.0.patch, HBASE-20544.1.patch,
> HBASE-20544.2.patch, HBASE-20544.addendum.0.patch
>
>
> Attempting to update hbase-downstreamer to use our 2.0.0 release fails with
> an invalid port in the event that {{hbase.localcluster.assign.random.ports}}
> isn't set (or is set to false, specifically):
> {code}
> 2018-05-08 06:10:06,508 ERROR [main] regionserver.HRegionServer
> (HRegionServer.java:(631)) - Failed construction RegionServer
> java.lang.IllegalArgumentException: port out of range:-1
> at java.net.InetSocketAddress.checkPort(InetSocketAddress.java:143)
> at java.net.InetSocketAddress.(InetSocketAddress.java:224)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.(RSRpcServices.java:1217)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.(RSRpcServices.java:1184)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.createRpcServices(HRegionServer.java:723)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:561)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.(MiniHBaseCluster.java:147)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.createRegionServerThread(JVMClusterUtil.java:86)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.addRegionServer(LocalHBaseCluster.java:184)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster$1.run(LocalHBaseCluster.java:198)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster$1.run(LocalHBaseCluster.java:195)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at
> org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:313)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.addRegionServer(LocalHBaseCluster.java:194)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:261)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:121)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1042)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:988)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:859)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:853)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:782)
> at
> org.hbase.downstreamer.TestHBaseMiniCluster.testSpinUpMiniHBaseCluster(TestHBaseMiniCluster.java:16)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
[jira] [Commented] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[
https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475773#comment-16475773
]
Hudson commented on HBASE-20564:
Results for branch master
[build #331 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/331/]: (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/331//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/331//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/331//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Tighter ByteBufferKeyValue Cell Comparator
> --
>
> Key: HBASE-20564
> URL: https://issues.apache.org/jira/browse/HBASE-20564
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: 1.4.pe.write.0510.96203.cpu.svg,
> 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg,
> HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch,
> HBASE-20564.branch-2.patch, hits.png
>
>
> Comparing Cells in hbase2 takes almost 3x the CPU.
> In hbase1, its a keyValue backed by a byte array caching a few important
> values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the
> row/family/qualifier lengths repeatedly.
> I tried making a purposed comparator -- one that was not generic -- and it
> seemed to have a nicer profile coming close to hbase1 in percentage used
> (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts
> attached to HBASE-20483). It doesn't work when I try to run it on cluster.
> Let me run unit tests to see if it can figure what I have wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475782#comment-16475782
]
Sean Busbey commented on HBASE-20444:
-
{quote}
3.commons-lang's StringUtils#isNumeric cannot pass checkstyle due to
checkstyle.xml
{code}
{code}
{quote}
We should probably give pointers here for what folks ought to use. The
commons-lang check here is trying to make sure folks don't use commons-lang
2.z. [the commons-lang 3 version of
StringUtils.isNumeric|https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/StringUtils.html#isNumeric-java.lang.CharSequence-]
should pass checkstyle.
That said, I don't think everything that {{StringUtils}} identifies as numeric
will pass muster with {{Integer.parseInt}}.
{code}
171 private static boolean isNumeric(String str) {
172 Pattern pattern = Pattern.compile("[0-9]*");
173 return pattern.matcher(str).matches();
174 }
{code}
Negative numbers get treated as strings for sort, is that intentional? What
happens when we pass in an integer > MAX_INT?
Can we include some erroneous version strings in the test set to make sure we
have fewer surprises in the future? like "foobar-1.2.3".
Also a comparison within alpha/beta to confirm numeric is being used amongst
them. e.g. "3.0.0-alpha-2" vs "3.0.0-alpha-11"
{code}
42 assertTrue(VersionInfo.compareVersion("2.0.0", "2.0.0.0") == 0);
{code}
I don't think this is correct. "critical patch 0" should be after the main
release. I'm not sure we've ever done a critical patch release, but still.
{code}
52 assertTrue(VersionInfo.compareVersion("2.0.0.1", "2.0.0-fuck") < 0);
53 assertTrue(VersionInfo.compareVersion("2.0.0-ooxx", "2.0.0.1") > 0);
{code}
No swears please. something like "2.0.0-foobar" would suffice for "there's a
label string we don't know about". Also, I think the ordering here is wrong as
well "2.0.0.1" would be "the second critical patch release on 2.0.0" should
occur after "2.0.0 with some caveat we don't recognize".
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Assignee: maoling
>Priority: Major
> Attachments: HBASE-20444.master.001.patch,
> HBASE-20444.master.002.patch, HBASE-20444.master.003.patch
>
>
> As [~busbey] commented on HBASE-18792, current logic for comparing version
> strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and
> needs to be improved:
> {code:java}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> {quote}I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> {quote}
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> {quote}Can we expand the versions checked in TestVersionInfo to include a)
> some "same major different minor", b) "same minor different maintenance", c)
> both of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20444) Improve version comparison logic for HBase specific version string and add unit tests
[
https://issues.apache.org/jira/browse/HBASE-20444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475793#comment-16475793
]
Sean Busbey commented on HBASE-20444:
-
{quote}
{code}
42 assertTrue(VersionInfo.compareVersion("2.0.0", "2.0.0.0") == 0);
{code}
I don't think this is correct. "critical patch 0" should be after the main
release. I'm not sure we've ever done a critical patch release, but still.
{quote}
Can confirm we've done 8:
* 0.94.6.1
* 0.96.1.1
* 0.98.6.1
* 0.98.10.1
* 0.98.12.1
* 0.98.16.1
* 1.0.1.1
* 1.1.0.1
They've all been 1 based, so I think they'd sort correctly? We should add a
test case that includes "critical patch release sorts after main release
number". the closest I see right now compares "2.0.0.1" and "2.0", and the
latter isn't a correct version number.
> Improve version comparison logic for HBase specific version string and add
> unit tests
> -
>
> Key: HBASE-20444
> URL: https://issues.apache.org/jira/browse/HBASE-20444
> Project: HBase
> Issue Type: Improvement
>Reporter: Umesh Agashe
>Assignee: maoling
>Priority: Major
> Attachments: HBASE-20444.master.001.patch,
> HBASE-20444.master.002.patch, HBASE-20444.master.003.patch
>
>
> As [~busbey] commented on HBASE-18792, current logic for comparing version
> strings in class org.apache.hadoop.hbase.util.VersionInfo is generic and
> needs to be improved:
> {code:java}
> if (index < s1.length) {
> // s1 is longer
> return 1;
> }
> {code}
> {quote}I think this is wrong? like version "2.0.0" should be after
> "2.0.0-SNAPSHOT". it's also after "2.0.0-alpha-3" or "2.0.0-beta-1".
> {quote}
> Also in other cases 2.0.0 should be before 2.0.0-patch- and 2.0.0.1. Also
> 2.0 should be before 2.0.1.
> {quote}Can we expand the versions checked in TestVersionInfo to include a)
> some "same major different minor", b) "same minor different maintenance", c)
> both of the above, but SNAPSHOT, d) "-alpha" / "-beta"?
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20457) Return immediately for a scan rpc call when we want to switch from pread to stream
[ https://issues.apache.org/jira/browse/HBASE-20457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20457: -- Component/s: scan > Return immediately for a scan rpc call when we want to switch from pread to > stream > -- > > Key: HBASE-20457 > URL: https://issues.apache.org/jira/browse/HBASE-20457 > Project: HBase > Issue Type: Bug > Components: scan >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20457-v1.patch, HBASE-20457.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20457) Return immediately for a scan rpc call when we want to switch from pread to stream
[ https://issues.apache.org/jira/browse/HBASE-20457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20457: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.1.0 3.0.0 Status: Resolved (was: Patch Available) Pushed to master and branch-2. Thanks [~ram_krish] for reviewing. > Return immediately for a scan rpc call when we want to switch from pread to > stream > -- > > Key: HBASE-20457 > URL: https://issues.apache.org/jira/browse/HBASE-20457 > Project: HBase > Issue Type: Bug > Components: scan >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20457-v1.patch, HBASE-20457.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20569) NPE in RecoverStandbyProcedure.execute
[
https://issues.apache.org/jira/browse/HBASE-20569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475817#comment-16475817
]
Duo Zhang commented on HBASE-20569:
---
OK it is a bug on master branch.
{code}
private void clearQueue() {
// Remove Servers
for (int i = 0; i < serverBuckets.length; ++i) {
clear(serverBuckets[i], serverRunQueue, SERVER_QUEUE_KEY_COMPARATOR);
serverBuckets[i] = null;
}
// Remove Tables
clear(tableMap, tableRunQueue, TABLE_QUEUE_KEY_COMPARATOR);
tableMap = null;
assert size() == 0 : "expected queue size to be 0, got " + size();
}
{code}
Here we do not remove the peerRunQueue...
Let me file an issue to fix this.
> NPE in RecoverStandbyProcedure.execute
> --
>
> Key: HBASE-20569
> URL: https://issues.apache.org/jira/browse/HBASE-20569
> Project: HBase
> Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Attachments: HBASE-20569.HBASE-19064.001.patch,
> HBASE-20569.HBASE-19064.002.patch
>
>
> We call ReplaySyncReplicationWALManager.initPeerWorkers in INIT_WORKERS state
> and then use it in DISPATCH_TASKS. But if we restart the master and the
> procedure is restarted from state DISPATCH_TASKS, no one will call the
> initPeerWorkers method and we will get NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20585) Need to clear peer map when clearing MasterProcedureScheduler
Duo Zhang created HBASE-20585: - Summary: Need to clear peer map when clearing MasterProcedureScheduler Key: HBASE-20585 URL: https://issues.apache.org/jira/browse/HBASE-20585 Project: HBase Issue Type: Bug Components: proc-v2 Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 3.0.0, 2.1.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20585) Need to clear peer map when clearing MasterProcedureScheduler
[ https://issues.apache.org/jira/browse/HBASE-20585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20585: -- Status: Patch Available (was: Open) > Need to clear peer map when clearing MasterProcedureScheduler > -- > > Key: HBASE-20585 > URL: https://issues.apache.org/jira/browse/HBASE-20585 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20585.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20585) Need to clear peer map when clearing MasterProcedureScheduler
[ https://issues.apache.org/jira/browse/HBASE-20585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475824#comment-16475824 ] Duo Zhang commented on HBASE-20585: --- [~zghaobac] Please try this patch to see if it works for you. Thanks. > Need to clear peer map when clearing MasterProcedureScheduler > -- > > Key: HBASE-20585 > URL: https://issues.apache.org/jira/browse/HBASE-20585 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20585.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20585) Need to clear peer map when clearing MasterProcedureScheduler
[ https://issues.apache.org/jira/browse/HBASE-20585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20585: -- Attachment: HBASE-20585.patch > Need to clear peer map when clearing MasterProcedureScheduler > -- > > Key: HBASE-20585 > URL: https://issues.apache.org/jira/browse/HBASE-20585 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20585.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-20586) SyncTable tool: Add support for cross-realm remote clusters
Wellington Chevreuil created HBASE-20586:
Summary: SyncTable tool: Add support for cross-realm remote
clusters
Key: HBASE-20586
URL: https://issues.apache.org/jira/browse/HBASE-20586
Project: HBase
Issue Type: Improvement
Components: mapreduce
Reporter: Wellington Chevreuil
Assignee: Wellington Chevreuil
One possible scenario for HashTable/SyncTable is for synchronize different
clusters, for instance, when replication has been enabled but data existed
already, or due replication issues that may had caused long lags in the
replication.
For secured clusters under different kerberos realms (with cross-realm properly
set), though, current SyncTable version would fail to authenticate with the
remote cluster when trying to read HashTable outputs (when *sourcehashdir* is
remote) and also when trying to read table data on the remote cluster (when
*sourcezkcluster* is remote).
The hdfs error would look like this:
{noformat}
INFO mapreduce.Job: Task Id : attempt_1524358175778_105392_m_00_0, Status :
FAILED
Error: java.io.IOException: Failed on local exception: java.io.IOException:
org.apache.hadoop.security.AccessControlException: Client cannot authenticate
via:[TOKEN, KERBEROS]; Host Details : local host is: "local-host/1.1.1.1";
destination host is: "remote-nn":8020;
at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
at org.apache.hadoop.ipc.Client.call(Client.java:1506)
at org.apache.hadoop.ipc.Client.call(Client.java:1439)
at
org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:230)
at com.sun.proxy.$Proxy13.getBlockLocations(Unknown Source)
at
org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getBlockLocations(ClientNamenodeProtocolTranslatorPB.java:256)
...
at
org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.readPropertiesFile(HashTable.java:144)
at
org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.read(HashTable.java:105)
at
org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.setup(SyncTable.java:188)
at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:142)
...
Caused by: java.io.IOException:
org.apache.hadoop.security.AccessControlException: Client cannot authenticate
via:[TOKEN, KERBEROS]{noformat}
The above can be sorted if the SyncTable job acquires a DT for the remote NN.
Once hdfs related authentication is done, it's also necessary to authenticate
against remote HBase, as the below error would arise:
{noformat}
INFO mapreduce.Job: Task Id : attempt_1524358175778_172414_m_00_0, Status :
FAILED
Error: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get the
location
at
org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:326)
...
at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:867)
at
org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.syncRange(SyncTable.java:331)
...
Caused by: java.io.IOException: Could not set up IO Streams to
remote-rs-host/1.1.1.2:60020
at
org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:786)
...
Caused by: java.lang.RuntimeException: SASL authentication failed. The most
likely cause is missing or invalid credentials. Consider 'kinit'.
...
Caused by: GSSException: No valid credentials provided (Mechanism level: Failed
to find any Kerberos tgt)
...{noformat}
The above would need additional authentication logic against the remote hbase
cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20586) SyncTable tool: Add support for cross-realm remote clusters
[
https://issues.apache.org/jira/browse/HBASE-20586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil updated HBASE-20586:
-
Attachment: HBASE-20586.master.001.patch
> SyncTable tool: Add support for cross-realm remote clusters
> ---
>
> Key: HBASE-20586
> URL: https://issues.apache.org/jira/browse/HBASE-20586
> Project: HBase
> Issue Type: Improvement
> Components: mapreduce
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-20586.master.001.patch
>
>
> One possible scenario for HashTable/SyncTable is for synchronize different
> clusters, for instance, when replication has been enabled but data existed
> already, or due replication issues that may had caused long lags in the
> replication.
> For secured clusters under different kerberos realms (with cross-realm
> properly set), though, current SyncTable version would fail to authenticate
> with the remote cluster when trying to read HashTable outputs (when
> *sourcehashdir* is remote) and also when trying to read table data on the
> remote cluster (when *sourcezkcluster* is remote).
> The hdfs error would look like this:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_105392_m_00_0, Status
> : FAILED
> Error: java.io.IOException: Failed on local exception: java.io.IOException:
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate
> via:[TOKEN, KERBEROS]; Host Details : local host is: "local-host/1.1.1.1";
> destination host is: "remote-nn":8020;
> at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
> at org.apache.hadoop.ipc.Client.call(Client.java:1506)
> at org.apache.hadoop.ipc.Client.call(Client.java:1439)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:230)
> at com.sun.proxy.$Proxy13.getBlockLocations(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getBlockLocations(ClientNamenodeProtocolTranslatorPB.java:256)
> ...
> at
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.readPropertiesFile(HashTable.java:144)
> at
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.read(HashTable.java:105)
> at
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.setup(SyncTable.java:188)
> at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:142)
> ...
> Caused by: java.io.IOException:
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate
> via:[TOKEN, KERBEROS]{noformat}
> The above can be sorted if the SyncTable job acquires a DT for the remote NN.
> Once hdfs related authentication is done, it's also necessary to authenticate
> against remote HBase, as the below error would arise:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_172414_m_00_0, Status
> : FAILED
> Error: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get
> the location
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:326)
> ...
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:867)
> at
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.syncRange(SyncTable.java:331)
> ...
> Caused by: java.io.IOException: Could not set up IO Streams to
> remote-rs-host/1.1.1.2:60020
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:786)
> ...
> Caused by: java.lang.RuntimeException: SASL authentication failed. The most
> likely cause is missing or invalid credentials. Consider 'kinit'.
> ...
> Caused by: GSSException: No valid credentials provided (Mechanism level:
> Failed to find any Kerberos tgt)
> ...{noformat}
> The above would need additional authentication logic against the remote hbase
> cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20586) SyncTable tool: Add support for cross-realm remote clusters
[
https://issues.apache.org/jira/browse/HBASE-20586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475922#comment-16475922
]
Wellington Chevreuil commented on HBASE-20586:
--
Initial patch proposal. Had worked on manual tests. Not sure how to add tests
to this, is there any existing template or example integration test for
cross-realm domains? I had looked at some kerberos related tests using
*MiniKdc* class, however I don't think it's able to emulate cross realm
environments with it. Any suggestions and/or ideas on testing are welcome.
> SyncTable tool: Add support for cross-realm remote clusters
> ---
>
> Key: HBASE-20586
> URL: https://issues.apache.org/jira/browse/HBASE-20586
> Project: HBase
> Issue Type: Improvement
> Components: mapreduce
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-20586.master.001.patch
>
>
> One possible scenario for HashTable/SyncTable is for synchronize different
> clusters, for instance, when replication has been enabled but data existed
> already, or due replication issues that may had caused long lags in the
> replication.
> For secured clusters under different kerberos realms (with cross-realm
> properly set), though, current SyncTable version would fail to authenticate
> with the remote cluster when trying to read HashTable outputs (when
> *sourcehashdir* is remote) and also when trying to read table data on the
> remote cluster (when *sourcezkcluster* is remote).
> The hdfs error would look like this:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_105392_m_00_0, Status
> : FAILED
> Error: java.io.IOException: Failed on local exception: java.io.IOException:
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate
> via:[TOKEN, KERBEROS]; Host Details : local host is: "local-host/1.1.1.1";
> destination host is: "remote-nn":8020;
> at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
> at org.apache.hadoop.ipc.Client.call(Client.java:1506)
> at org.apache.hadoop.ipc.Client.call(Client.java:1439)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:230)
> at com.sun.proxy.$Proxy13.getBlockLocations(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getBlockLocations(ClientNamenodeProtocolTranslatorPB.java:256)
> ...
> at
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.readPropertiesFile(HashTable.java:144)
> at
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.read(HashTable.java:105)
> at
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.setup(SyncTable.java:188)
> at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:142)
> ...
> Caused by: java.io.IOException:
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate
> via:[TOKEN, KERBEROS]{noformat}
> The above can be sorted if the SyncTable job acquires a DT for the remote NN.
> Once hdfs related authentication is done, it's also necessary to authenticate
> against remote HBase, as the below error would arise:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_172414_m_00_0, Status
> : FAILED
> Error: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get
> the location
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:326)
> ...
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:867)
> at
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.syncRange(SyncTable.java:331)
> ...
> Caused by: java.io.IOException: Could not set up IO Streams to
> remote-rs-host/1.1.1.2:60020
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:786)
> ...
> Caused by: java.lang.RuntimeException: SASL authentication failed. The most
> likely cause is missing or invalid credentials. Consider 'kinit'.
> ...
> Caused by: GSSException: No valid credentials provided (Mechanism level:
> Failed to find any Kerberos tgt)
> ...{noformat}
> The above would need additional authentication logic against the remote hbase
> cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20586) SyncTable tool: Add support for cross-realm remote clusters
[
https://issues.apache.org/jira/browse/HBASE-20586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-20586:
Component/s: Replication
> SyncTable tool: Add support for cross-realm remote clusters
> ---
>
> Key: HBASE-20586
> URL: https://issues.apache.org/jira/browse/HBASE-20586
> Project: HBase
> Issue Type: Improvement
> Components: mapreduce, Replication
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Minor
> Attachments: HBASE-20586.master.001.patch
>
>
> One possible scenario for HashTable/SyncTable is for synchronize different
> clusters, for instance, when replication has been enabled but data existed
> already, or due replication issues that may had caused long lags in the
> replication.
> For secured clusters under different kerberos realms (with cross-realm
> properly set), though, current SyncTable version would fail to authenticate
> with the remote cluster when trying to read HashTable outputs (when
> *sourcehashdir* is remote) and also when trying to read table data on the
> remote cluster (when *sourcezkcluster* is remote).
> The hdfs error would look like this:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_105392_m_00_0, Status
> : FAILED
> Error: java.io.IOException: Failed on local exception: java.io.IOException:
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate
> via:[TOKEN, KERBEROS]; Host Details : local host is: "local-host/1.1.1.1";
> destination host is: "remote-nn":8020;
> at org.apache.hadoop.net.NetUtils.wrapException(NetUtils.java:772)
> at org.apache.hadoop.ipc.Client.call(Client.java:1506)
> at org.apache.hadoop.ipc.Client.call(Client.java:1439)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:230)
> at com.sun.proxy.$Proxy13.getBlockLocations(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getBlockLocations(ClientNamenodeProtocolTranslatorPB.java:256)
> ...
> at
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.readPropertiesFile(HashTable.java:144)
> at
> org.apache.hadoop.hbase.mapreduce.HashTable$TableHash.read(HashTable.java:105)
> at
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.setup(SyncTable.java:188)
> at org.apache.hadoop.mapreduce.Mapper.run(Mapper.java:142)
> ...
> Caused by: java.io.IOException:
> org.apache.hadoop.security.AccessControlException: Client cannot authenticate
> via:[TOKEN, KERBEROS]{noformat}
> The above can be sorted if the SyncTable job acquires a DT for the remote NN.
> Once hdfs related authentication is done, it's also necessary to authenticate
> against remote HBase, as the below error would arise:
> {noformat}
> INFO mapreduce.Job: Task Id : attempt_1524358175778_172414_m_00_0, Status
> : FAILED
> Error: org.apache.hadoop.hbase.client.RetriesExhaustedException: Can't get
> the location
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:326)
> ...
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:867)
> at
> org.apache.hadoop.hbase.mapreduce.SyncTable$SyncMapper.syncRange(SyncTable.java:331)
> ...
> Caused by: java.io.IOException: Could not set up IO Streams to
> remote-rs-host/1.1.1.2:60020
> at
> org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:786)
> ...
> Caused by: java.lang.RuntimeException: SASL authentication failed. The most
> likely cause is missing or invalid credentials. Consider 'kinit'.
> ...
> Caused by: GSSException: No valid credentials provided (Mechanism level:
> Failed to find any Kerberos tgt)
> ...{noformat}
> The above would need additional authentication logic against the remote hbase
> cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20566) Creating a system table after enabling rsgroup feature puts region into RIT
[
https://issues.apache.org/jira/browse/HBASE-20566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475931#comment-16475931
]
Biju Nair commented on HBASE-20566:
---
Thanks [~yuzhih...@gmail.com]/[~nihaljain.cs]. Apologies for the late query.
Will the change handle the scenario where {{hbase}} namespace is assigned to a
non {{default}} namespace by the user before enabling {{Quota}}? Or the
requirement/assumption is that {{hbase}} namespace should be in {{default}}
namespace.
> Creating a system table after enabling rsgroup feature puts region into RIT
> ---
>
> Key: HBASE-20566
> URL: https://issues.apache.org/jira/browse/HBASE-20566
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Biju Nair
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20566.master.001.patch,
> HBASE-20566.master.002.patch
>
>
> *Steps to reproduce*
> - Enable {{rsgroup}} feature
> - Enable {{quota}} feature which created {{hbase::quota}} table
> - quota table region will be marked as RIT since the {{rsgroup}} for the
> table is not known
> {noformat}
> 2018-05-10 14:33:32,392 INFO [ProcedureExecutorThread-0]
> zookeeper.ZKTableStateManager: Moving table hbase:quota state from null to
> ENABLING
> 2018-05-10 14:33:32,397 WARN [ProcedureExecutorThread-0]
> rsgroup.RSGroupBasedLoadBalancer: Group for table hbase:quota is null
> 2018-05-10 14:33:32,398 WARN [ProcedureExecutorThread-0]
> master.RegionStates: Failed to open/close 89490cd5e00ea8948af413a1df65091a on
> null, set to FAILED_OPEN
> 2018-05-10 14:33:32,398 INFO [ProcedureExecutorThread-0]
> master.RegionStates: Transition {89490cd5e00ea8948af413a1df65091a
> state=OFFLINE, ts=1525977212397, server=null} to
> {89490cd5e00ea8948af413a1df65091a state=FAILED_OPEN, ts=1525977212398,
> server=null}
> 2018-05-10 14:33:32,398 INFO [ProcedureExecutorThread-0]
> zookeeper.ZKTableStateManager: Moving table hbase:quota state from ENABLING
> to ENABLED
> {noformat}
> - Reason for this issue: Issue
> - [system table
> creation|https://github.com/apache/hbase/blob/061a31fad1654d9ded96d118e04c14860413fa25/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java#L1793]
> doesn't move the table to the appropriate rs group to which system namespace
> is assigned to. Need to execute logic similar to what is done in the
> RSGroupAdminEndpoint for [post table creation|#L377] for user table creation.
> *Work Around*
> - Assigning the system table to ``default`` rsgroup (or to the rsgroup to
> which the system namespace has been assigned).
> - Manually assigning the region in RIT from the system table
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20585) Need to clear peer map when clearing MasterProcedureScheduler
[
https://issues.apache.org/jira/browse/HBASE-20585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475937#comment-16475937
]
Hadoop QA commented on HBASE-20585:
---
| (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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
20s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
59s{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} 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}
13m 10s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 34m 39s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 75m 7s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.ipc.TestSimpleRpcScheduler |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20585 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923482/HBASE-20585.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 92eed066383d 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / 26babcf013 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12825/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12825/testRepor
[jira] [Updated] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20564: --- Attachment: 20564.addendum > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[
https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16475954#comment-16475954
]
Ted Yu commented on HBASE-20564:
There were several unit tests broken where MetaCellComparator is involved.
To be specific, even though left and right Cells are instances of
ByteBufferKeyValue, the optimized path in method
{code}
compare(final Cell a, final Cell b, boolean ignoreSequenceid)
{code}
should not be taken since row comparison in MetaCellComparator involves (meta)
row delimiter.
The attached addendum lets MetaCellComparator override the above method by
calling the previous version.
> Tighter ByteBufferKeyValue Cell Comparator
> --
>
> Key: HBASE-20564
> URL: https://issues.apache.org/jira/browse/HBASE-20564
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: 1.4.pe.write.0510.96203.cpu.svg,
> 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum,
> HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch,
> HBASE-20564.branch-2.patch, hits.png
>
>
> Comparing Cells in hbase2 takes almost 3x the CPU.
> In hbase1, its a keyValue backed by a byte array caching a few important
> values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the
> row/family/qualifier lengths repeatedly.
> I tried making a purposed comparator -- one that was not generic -- and it
> seemed to have a nicer profile coming close to hbase1 in percentage used
> (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts
> attached to HBASE-20483). It doesn't work when I try to run it on cluster.
> Let me run unit tests to see if it can figure what I have wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20569) NPE in RecoverStandbyProcedure.execute
[
https://issues.apache.org/jira/browse/HBASE-20569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476017#comment-16476017
]
Hadoop QA commented on HBASE-20569:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 3m
11s{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} HBASE-19064 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
39s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
4s{color} | {color:green} HBASE-19064 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} 1m
57s{color} | {color:green} HBASE-19064 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} HBASE-19064 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
5s{color} | {color:red} hbase-server: The patch generated 2 new + 160 unchanged
- 0 fixed = 162 total (was 160) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
12s{color} | {color:red} patch has 10 errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
13m 46s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 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
33s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}167m
12s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 0m
25s{color} | {color:red} The patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}212m 12s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20569 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923465/HBASE-20569.HBASE-19064.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 240c13abb41b 4.4.0-104-generic #127-Ubuntu SMP Mon Dec 11
12:16:42 UTC 2017 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | HBASE-19064 / 5d5c2d204b |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12824/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| shadedjars |
https://builds.apache.org/job/PreCommit-HBASE-Build/12824/artifact/patchprocess/patch-shadedjars.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12
[jira] [Commented] (HBASE-20566) Creating a system table after enabling rsgroup feature puts region into RIT
[
https://issues.apache.org/jira/browse/HBASE-20566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476021#comment-16476021
]
Mike Drob commented on HBASE-20566:
---
[~yuzhih...@gmail.com], [~nihaljain.cs] - does this affect 2.0 as well? should
we apply the patch to older branches?
fyi: [~stack]
> Creating a system table after enabling rsgroup feature puts region into RIT
> ---
>
> Key: HBASE-20566
> URL: https://issues.apache.org/jira/browse/HBASE-20566
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Biju Nair
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20566.master.001.patch,
> HBASE-20566.master.002.patch
>
>
> *Steps to reproduce*
> - Enable {{rsgroup}} feature
> - Enable {{quota}} feature which created {{hbase::quota}} table
> - quota table region will be marked as RIT since the {{rsgroup}} for the
> table is not known
> {noformat}
> 2018-05-10 14:33:32,392 INFO [ProcedureExecutorThread-0]
> zookeeper.ZKTableStateManager: Moving table hbase:quota state from null to
> ENABLING
> 2018-05-10 14:33:32,397 WARN [ProcedureExecutorThread-0]
> rsgroup.RSGroupBasedLoadBalancer: Group for table hbase:quota is null
> 2018-05-10 14:33:32,398 WARN [ProcedureExecutorThread-0]
> master.RegionStates: Failed to open/close 89490cd5e00ea8948af413a1df65091a on
> null, set to FAILED_OPEN
> 2018-05-10 14:33:32,398 INFO [ProcedureExecutorThread-0]
> master.RegionStates: Transition {89490cd5e00ea8948af413a1df65091a
> state=OFFLINE, ts=1525977212397, server=null} to
> {89490cd5e00ea8948af413a1df65091a state=FAILED_OPEN, ts=1525977212398,
> server=null}
> 2018-05-10 14:33:32,398 INFO [ProcedureExecutorThread-0]
> zookeeper.ZKTableStateManager: Moving table hbase:quota state from ENABLING
> to ENABLED
> {noformat}
> - Reason for this issue: Issue
> - [system table
> creation|https://github.com/apache/hbase/blob/061a31fad1654d9ded96d118e04c14860413fa25/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java#L1793]
> doesn't move the table to the appropriate rs group to which system namespace
> is assigned to. Need to execute logic similar to what is done in the
> RSGroupAdminEndpoint for [post table creation|#L377] for user table creation.
> *Work Around*
> - Assigning the system table to ``default`` rsgroup (or to the rsgroup to
> which the system namespace has been assigned).
> - Manually assigning the region in RIT from the system table
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476079#comment-16476079
]
Josh Elser commented on HBASE-20582:
Jackson CVE's are remote-code execution grade issues, but actually seem to only
be applicable when certain Spring or c3p0 libraries are on the classpath. I
think I missed that these were only applicable sometimes. However, it seems
like our use jackson client-side is pretty bogus too. We have it solely for
some JSON representation of JMX MBeans which are only used server-side that I
can tell. I think we could move this to hbase-http and avoid Jackson client
side entirely (for non-shaded clients, obviously) which should remove concern
for us controlling Jackson version, right?
The Ruby CVEs are very.. obtuse. JRuby appears to copy the stdlib from MRI
Ruby, at which point we should be trusting JRuby to tell us when we need to
upgrade. However, their security page was last updated in 2011 (sigh). Most
CVEs in this list appear to not affect us, but CVE-2017-10784 might. It seems
like our 9.1.10.0 version has stdlib from Ruby 2.3.5 and this hasn't changed.
The version of RubyGems has changed slightly in newer versions (2.6.11 to
2.6.14)
For JRuby, this is all to say, I think the risk is less purely because we're
not running some daemon/service; the vector is a user running untrusted code
and shooting themselves in the foot. I think avoiding the JRuby upgrade for
2.0.x is fine. But for 2.1.x it would be good ([~Apache9])? If nothing else,
for master.
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-20582:
---
Status: Patch Available (was: Open)
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20587) Remove client-side Jackson dependency
Josh Elser created HBASE-20587: -- Summary: Remove client-side Jackson dependency Key: HBASE-20587 URL: https://issues.apache.org/jira/browse/HBASE-20587 Project: HBase Issue Type: Bug Components: dependencies Reporter: Josh Elser Assignee: Josh Elser HBASE-20582 got me looking at how we use Jackson. It appears that we moved some JSON code from hbase-server into hbase-common via HBASE-19053. But, there seems to be no good reason why this code should live there and not in hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20587) Remove client-side Jackson dependency
[ https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476102#comment-16476102 ] Josh Elser commented on HBASE-20587: Argh, missed that hbase-client still has a reference to Jackson's JsonMapper. > Remove client-side Jackson dependency > - > > Key: HBASE-20587 > URL: https://issues.apache.org/jira/browse/HBASE-20587 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > > HBASE-20582 got me looking at how we use Jackson. It appears that we moved > some JSON code from hbase-server into hbase-common via HBASE-19053. But, > there seems to be no good reason why this code should live there and not in > hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. > FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20587) Remove hbase-common Jackson dependency
[ https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-20587: --- Summary: Remove hbase-common Jackson dependency (was: Remove client-side Jackson dependency) > Remove hbase-common Jackson dependency > -- > > Key: HBASE-20587 > URL: https://issues.apache.org/jira/browse/HBASE-20587 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > > HBASE-20582 got me looking at how we use Jackson. It appears that we moved > some JSON code from hbase-server into hbase-common via HBASE-19053. But, > there seems to be no good reason why this code should live there and not in > hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. > FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20587) Remove hbase-common Jackson dependency
[
https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476110#comment-16476110
]
Josh Elser commented on HBASE-20587:
Looks like we can't rip out Jackson from the hbase-client as all operations
(e.g. Get, Put) use it for implementing {{toString()}}.
Can still pull it out of hbase-common and put that server-side in hbase-http.
> Remove hbase-common Jackson dependency
> --
>
> Key: HBASE-20587
> URL: https://issues.apache.org/jira/browse/HBASE-20587
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
>
> HBASE-20582 got me looking at how we use Jackson. It appears that we moved
> some JSON code from hbase-server into hbase-common via HBASE-19053. But,
> there seems to be no good reason why this code should live there and not in
> hbase-http instead. Keeping Jackson off the user's classpath is a nice goal.
> FYI [~appy], [~mdrob]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20587) Remove hbase-common Jackson dependency
[ https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-20587: --- Attachment: HBASE-20587.001.patch > Remove hbase-common Jackson dependency > -- > > Key: HBASE-20587 > URL: https://issues.apache.org/jira/browse/HBASE-20587 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-20587.001.patch > > > HBASE-20582 got me looking at how we use Jackson. It appears that we moved > some JSON code from hbase-server into hbase-common via HBASE-19053. But, > there seems to be no good reason why this code should live there and not in > hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. > FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20587) Remove hbase-common Jackson dependency
[ https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476112#comment-16476112 ] Mike Drob commented on HBASE-20587: --- You mean our JsonMapper has a reference to Jackson's ObjectMapper. > Remove hbase-common Jackson dependency > -- > > Key: HBASE-20587 > URL: https://issues.apache.org/jira/browse/HBASE-20587 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-20587.001.patch > > > HBASE-20582 got me looking at how we use Jackson. It appears that we moved > some JSON code from hbase-server into hbase-common via HBASE-19053. But, > there seems to be no good reason why this code should live there and not in > hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. > FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20587) Remove hbase-common Jackson dependency
[ https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-20587: --- Status: Patch Available (was: Open) > Remove hbase-common Jackson dependency > -- > > Key: HBASE-20587 > URL: https://issues.apache.org/jira/browse/HBASE-20587 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-20587.001.patch > > > HBASE-20582 got me looking at how we use Jackson. It appears that we moved > some JSON code from hbase-server into hbase-common via HBASE-19053. But, > there seems to be no good reason why this code should live there and not in > hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. > FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20587) Remove hbase-common Jackson dependency
[ https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476117#comment-16476117 ] Mike Drob commented on HBASE-20587: --- should we shade jackson in hbase-thirdparty? > Remove hbase-common Jackson dependency > -- > > Key: HBASE-20587 > URL: https://issues.apache.org/jira/browse/HBASE-20587 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-20587.001.patch > > > HBASE-20582 got me looking at how we use Jackson. It appears that we moved > some JSON code from hbase-server into hbase-common via HBASE-19053. But, > there seems to be no good reason why this code should live there and not in > hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. > FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476147#comment-16476147
]
Josh Elser commented on HBASE-20582:
{quote}Jackson CVE's are remote-code execution grade issues, but actually seem
to only be applicable when certain Spring or c3p0 libraries are on the
classpath.
{quote}
I think this might be an issue for us in the 2.x line. Looking solely at us in
HBase, we aren't affected by the Jackson CVEs.
However, since Jackson does exist client-side as well, we have to think about
how our users will be using hbase-client and what dependencies they may have.
In other words, a user may use Spring in their HBase application and have a
problem where the necessary version of Jackson they need to avoid the security
hole is incompatible with the one we ship. I think this leaves two questions:
# Is Jackson shade-able?
# Are there incompatibilities between Jackson 2.9.2 and 2.9.5?
I don't know the answer to either at this point.
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476148#comment-16476148
]
Sean Busbey commented on HBASE-20582:
-
yeah that all sounds reasonable. given these tools have super high
false-positive rates I just want to make sure we're not a) jumping in
lower-risk upgrade paths without some analysis and b) causing noise for our
downstreams by essentially pushing the "are these CVEs actually relevant" off
to them.
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20587) Remove hbase-common Jackson dependency
[
https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476150#comment-16476150
]
Josh Elser commented on HBASE-20587:
{quote}You mean our JsonMapper has a reference to Jackson's ObjectMapper.
{quote}
Yes, thank you :)
{quote}should we shade jackson in hbase-thirdparty?
{quote}
Just had that same thought over on HBASE-20852. I'm not sure if there's a
reason we haven't yet shaded it, but that would help.
> Remove hbase-common Jackson dependency
> --
>
> Key: HBASE-20587
> URL: https://issues.apache.org/jira/browse/HBASE-20587
> Project: HBase
> Issue Type: Bug
> Components: dependencies
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Attachments: HBASE-20587.001.patch
>
>
> HBASE-20582 got me looking at how we use Jackson. It appears that we moved
> some JSON code from hbase-server into hbase-common via HBASE-19053. But,
> there seems to be no good reason why this code should live there and not in
> hbase-http instead. Keeping Jackson off the user's classpath is a nice goal.
> FYI [~appy], [~mdrob]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476151#comment-16476151
]
Sean Busbey commented on HBASE-20582:
-
> Is Jackson shade-able?
We shade it in our client, so hopefully.
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang updated HBASE-20488: Attachment: (was: HBASE-20488.master.001.patch) > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Assignee: Xu Cang >Priority: Minor > Labels: beginner > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476153#comment-16476153
]
Sean Busbey commented on HBASE-20582:
-
the shading makes it worse in some sense, btw. since it's substantially harder
for a downstream user to upgrade that version.
removing jackson from the client path makes sense, imho.
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang reassigned HBASE-20488: --- Assignee: Xu Cang > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Assignee: Xu Cang >Priority: Minor > Labels: beginner > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20587) Remove hbase-common Jackson dependency
[ https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-20587: --- Fix Version/s: 3.0.0 > Remove hbase-common Jackson dependency > -- > > Key: HBASE-20587 > URL: https://issues.apache.org/jira/browse/HBASE-20587 > Project: HBase > Issue Type: Bug > Components: dependencies >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20587.001.patch > > > HBASE-20582 got me looking at how we use Jackson. It appears that we moved > some JSON code from hbase-server into hbase-common via HBASE-19053. But, > there seems to be no good reason why this code should live there and not in > hbase-http instead. Keeping Jackson off the user's classpath is a nice goal. > FYI [~appy], [~mdrob] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang updated HBASE-20488: Attachment: HBASE-20488.master.001.patch > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Assignee: Xu Cang >Priority: Minor > Labels: beginner > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang updated HBASE-20488: Attachment: HBASE-20488.master.001.patch Tags: PerformanceEvaluation, PE Status: Patch Available (was: Open) Tested by conducting pe help command, result as below: myid@myhost:~//hbase$ bin/hbase pe -h Usage: hbase pe \ [-D]* > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Assignee: Xu Cang >Priority: Minor > Labels: beginner > Attachments: HBASE-20488.master.001.patch > > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476161#comment-16476161
]
Josh Elser commented on HBASE-20582:
{quote}We shade it in our client, so hopefully.
{quote}
lol, right. Duh. :)
{quote}the shading makes it worse in some sense, btw. since it's substantially
harder for a downstream user to upgrade that version.
{quote}
My thinking was that when we "hide" Jackson, we take the onus to make sure we
aren't shipping a version of Jackson which HBase itself is vulnerable to (e.g.
when no Spring on the classpath, we're ok). I am expecting that a user with
Spring on their classpath and our shaded Jackson version wouldn't be vulnerable
to the CVE as a result of us (because they wouldn't know to use our version –
they'd use their own at the normal Java coordinates).
{quote}removing jackson from the client path makes sense, imho.
{quote}
Could swap out Jackson for a GSON (or any other lib). not sure if that's just
trading one set of problems for another, ya know?
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476169#comment-16476169
]
Sean Busbey commented on HBASE-20582:
-
{quote}
bq. the shading makes it worse in some sense, btw. since it's substantially
harder for a downstream user to upgrade that version.
My thinking was that when we "hide" Jackson, we take the onus to make sure we
aren't shipping a version of Jackson which HBase itself is vulnerable to (e.g.
when no Spring on the classpath, we're ok). I am expecting that a user with
Spring on their classpath and our shaded Jackson version wouldn't be vulnerable
to the CVE as a result of us (because they wouldn't know to use our version –
they'd use their own at the normal Java coordinates).
{quote}
that only works if we ensure nothing we have is exposed by the Java Services
API in a way that the end user might change the mix of runtime stuff. we might
do that. I'm not sure. there's definitely no test for it in place.
{quote}
bq. removing jackson from the client path makes sense, imho.
Could swap out Jackson for a GSON (or any other lib). not sure if that's just
trading one set of problems for another, ya know?
{quote}
I was hoping for your "we don't need to handle json here" solution to pan out.
:)
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-19798) Retry time should not be 0
[
https://issues.apache.org/jira/browse/HBASE-19798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Cang reassigned HBASE-19798:
---
Assignee: Xu Cang
> Retry time should not be 0
> --
>
> Key: HBASE-19798
> URL: https://issues.apache.org/jira/browse/HBASE-19798
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 1.2.6
> Environment: linux centos 6.5
> jdk 1.8
>
>
>Reporter: chenrongwei
>Assignee: Xu Cang
>Priority: Minor
> Attachments: HBASE-19798.branch-1.001.patch
>
>
> hbase.client.retries.number should not be set to zero.
> if set to zero will cause ConnectionManager report
> NoServerForRegionException.
> source code detail in 1.2.6's ConnectionManager like belows:
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
> if (tries >= localNumRetries)
> { throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + localNumRetries + " tries."); }
> actual exception info
> org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find
> region for 196053079 in fin_tech:crawler_event after 0 tries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-19798) Retry time should not be 0
[
https://issues.apache.org/jira/browse/HBASE-19798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xu Cang updated HBASE-19798:
Attachment: HBASE-19798.branch-1.001.patch
Status: Patch Available (was: Open)
> Retry time should not be 0
> --
>
> Key: HBASE-19798
> URL: https://issues.apache.org/jira/browse/HBASE-19798
> Project: HBase
> Issue Type: Bug
> Components: hbase
>Affects Versions: 1.2.6
> Environment: linux centos 6.5
> jdk 1.8
>
>
>Reporter: chenrongwei
>Priority: Minor
> Attachments: HBASE-19798.branch-1.001.patch
>
>
> hbase.client.retries.number should not be set to zero.
> if set to zero will cause ConnectionManager report
> NoServerForRegionException.
> source code detail in 1.2.6's ConnectionManager like belows:
> int localNumRetries = (retry ? numTries : 1);
> for (int tries = 0; true; tries++) {
> if (tries >= localNumRetries)
> { throw new NoServerForRegionException("Unable to find region for "
> + Bytes.toStringBinary(row) + " in " + tableName +
> " after " + localNumRetries + " tries."); }
> actual exception info
> org.apache.hadoop.hbase.client.NoServerForRegionException: Unable to find
> region for 196053079 in fin_tech:crawler_event after 0 tries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20587) Remove hbase-common Jackson dependency
[
https://issues.apache.org/jira/browse/HBASE-20587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476269#comment-16476269
]
Hadoop QA commented on HBASE-20587:
---
| (x) *{color:red}-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} 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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} master 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} 4m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
28s{color} | {color:green} hbase-common generated 0 new + 40 unchanged - 1
fixed = 40 total (was 41) {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 22s{color}
| {color:red} hbase-http generated 1 new + 17 unchanged - 0 fixed = 18 total
(was 17) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s{color} | {color:green} hbase-common: The patch generated 0 new + 0
unchanged - 11 fixed = 0 total (was 11) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
12s{color} | {color:red} hbase-http: The patch generated 11 new + 0 unchanged -
0 fixed = 11 total (was 0) {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
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
53s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 12s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
47s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
55s{color} | {color:green} hbase-http in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 47m 19s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/No
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476270#comment-16476270
]
Josh Elser commented on HBASE-20582:
{quote}that only works if we ensure nothing we have is exposed by the Java
Services API in a way that the end user might change the mix of runtime stuff.
we might do that. I'm not sure. there's definitely no test for it in place.
{quote}
Ah, good point. I'd apt to agree with you.
{quote}I was hoping for your "we don't need to handle json here" solution to
pan out.
{quote}
Yeah, I hear you. I guess we could roll our own toString() implementations for
the Operations instead of Jackson (or anything else).
Seems like the overall consensus is that we aren't concerned enough about these
dependencies to bump these dependencies right now? If that's the case, we can
just make this change in Master, and work towards pulling out Jackson (JSON)
entirely from hbase-client as a separate task. Thoughts?
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476281#comment-16476281
]
Sean Busbey commented on HBASE-20582:
-
These aren't big version changes, seems like they should be okay in a 2.1.0.
[~an...@apache.org] are you up for summarizing what changed that could be risky?
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476288#comment-16476288
]
Josh Elser commented on HBASE-20582:
{quote}are you up for summarizing what changed that could be risky?
{quote}
I can weigh in here that Jackson 2.9 claims to have compatibility (across the
versions we have). JRuby asserts the same (Ruby 2.3.0 compatibility, I think it
was). My big concern is just the "unknown" :)
I'd leave it to [~Apache9] to weigh in if this is desirable for 2.1 or not. I
know we shared the goal of trying to keep minor releases more slim.
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
> Project: HBase
> Issue Type: Bug
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 2.1.0
>
> Attachments: HBASE-20582.patch
>
>
> There are some vulnerabilities reported with two of the libraries used in
> HBase.
> {code}
> Jackson(version:2.9.2):
> CVE-2017-17485
> CVE-2018-5968
> CVE-2018-7489
> Jruby(version:9.1.10.0):
> CVE-2009-5147
> CVE-2013-4363
> CVE-2014-4975
> CVE-2014-8080
> CVE-2014-8090
> CVE-2015-3900
> CVE-2015-7551
> CVE-2015-9096
> CVE-2017-0899
> CVE-2017-0900
> CVE-2017-0901
> CVE-2017-0902
> CVE-2017-0903
> CVE-2017-10784
> CVE-2017-14064
> CVE-2017-9224
> CVE-2017-9225
> CVE-2017-9226
> CVE-2017-9227
> CVE-2017-9228
> {code}
> Tool somehow able to relate the vulnerability of Ruby with JRuby(Java
> implementation).
> Not all of them directly affects HBase but [~elserj] suggested that it is
> better to be on the updated version to avoid issues during an audit in
> security sensitive organization.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20488) PE tool prints full name in help message
[
https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476289#comment-16476289
]
Hadoop QA commented on HBASE-20488:
---
| (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 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
14s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
28s{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} 6m
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}
21m 44s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
12s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 12m 42s{color}
| {color:red} hbase-mapreduce in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 59m 28s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.mapreduce.TestHashTable |
| | hadoop.hbase.mapreduce.TestSyncTable |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20488 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923521/HBASE-20488.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 34b3ec78aacd 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / 26babcf013 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12828/artifact/patchprocess/patch-unit-hbase-mapreduce.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12828/testReport/ |
| Max. process+thread count | 4908 (vs. ulimit of 1) |
| mo
[jira] [Updated] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang updated HBASE-20488: Attachment: HBASE-20488.master.001.patch > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Assignee: Xu Cang >Priority: Minor > Labels: beginner > Attachments: HBASE-20488.master.001.patch > > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20488) PE tool prints full name in help message
[ https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xu Cang updated HBASE-20488: Attachment: (was: HBASE-20488.master.001.patch) > PE tool prints full name in help message > > > Key: HBASE-20488 > URL: https://issues.apache.org/jira/browse/HBASE-20488 > Project: HBase > Issue Type: Improvement > Components: shell >Affects Versions: 3.0.0 >Reporter: Peter Somogyi >Assignee: Xu Cang >Priority: Minor > Labels: beginner > Attachments: HBASE-20488.master.001.patch > > > The PerfomanceEvaluation tool currently prints its full path in help message > instead of short name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19798) Retry time should not be 0
[
https://issues.apache.org/jira/browse/HBASE-19798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476319#comment-16476319
]
Hadoop QA commented on HBASE-19798:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
28s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
2s{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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
8s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green} branch-1 passed with JDK v1.8.0_172 {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
10s{color} | {color:red} hbase-client in branch-1 failed with JDK v1.7.0_181.
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
4s{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
24s{color} | {color:green} branch-1 passed with JDK v1.8.0_172 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} branch-1 passed with JDK v1.7.0_181 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed with JDK v1.8.0_172 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
11s{color} | {color:red} hbase-client in the patch failed with JDK v1.7.0_181.
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 11s{color}
| {color:red} hbase-client in the patch failed with JDK v1.7.0_181. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s{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
58s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
6s{color} | {color:red} The patch causes 44 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m
9s{color} | {color:red} The patch causes 44 errors with Hadoop v2.5.2. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
23s{color} | {color:green} the patch passed with JDK v1.8.0_172 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} the patch passed with JDK v1.7.0_181 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
32s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 24m 11s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:36a7029 |
| JIRA Issue | HBASE-19798 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923525
[jira] [Updated] (HBASE-20530) Composition of backup directory containing namespace when restoring is different from the actual hfile location
[
https://issues.apache.org/jira/browse/HBASE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-20530:
--
Attachment: (was: HBASE-20530-v3.patch)
> Composition of backup directory containing namespace when restoring is
> different from the actual hfile location
> ---
>
> Key: HBASE-20530
> URL: https://issues.apache.org/jira/browse/HBASE-20530
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Critical
> Attachments: HBASE-20530-v1.patch, HBASE-20530-v2.patch,
> HBASE-20530-v3.patch
>
>
> Here is partial listing of output from incremental backup:
> {code}
> 5306 2018-05-04 02:38
> hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/table_almphxih4u/cf1/5648501da7194783947bbf07b172f07e
> {code}
> When restoring, here is what HBackupFileSystem.getTableBackupDir returns:
> {code}
> fileBackupDir=hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/default/table_almphxih4u
> {code}
> You can see that namespace gets in the way, leading to inability of finding
> the proper hfile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20530) Composition of backup directory containing namespace when restoring is different from the actual hfile location
[
https://issues.apache.org/jira/browse/HBASE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-20530:
--
Status: Open (was: Patch Available)
> Composition of backup directory containing namespace when restoring is
> different from the actual hfile location
> ---
>
> Key: HBASE-20530
> URL: https://issues.apache.org/jira/browse/HBASE-20530
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Critical
> Attachments: HBASE-20530-v1.patch, HBASE-20530-v2.patch,
> HBASE-20530-v3.patch
>
>
> Here is partial listing of output from incremental backup:
> {code}
> 5306 2018-05-04 02:38
> hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/table_almphxih4u/cf1/5648501da7194783947bbf07b172f07e
> {code}
> When restoring, here is what HBackupFileSystem.getTableBackupDir returns:
> {code}
> fileBackupDir=hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/default/table_almphxih4u
> {code}
> You can see that namespace gets in the way, leading to inability of finding
> the proper hfile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20530) Composition of backup directory containing namespace when restoring is different from the actual hfile location
[
https://issues.apache.org/jira/browse/HBASE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-20530:
--
Attachment: HBASE-20530-v3.patch
> Composition of backup directory containing namespace when restoring is
> different from the actual hfile location
> ---
>
> Key: HBASE-20530
> URL: https://issues.apache.org/jira/browse/HBASE-20530
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Critical
> Attachments: HBASE-20530-v1.patch, HBASE-20530-v2.patch,
> HBASE-20530-v3.patch
>
>
> Here is partial listing of output from incremental backup:
> {code}
> 5306 2018-05-04 02:38
> hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/table_almphxih4u/cf1/5648501da7194783947bbf07b172f07e
> {code}
> When restoring, here is what HBackupFileSystem.getTableBackupDir returns:
> {code}
> fileBackupDir=hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/default/table_almphxih4u
> {code}
> You can see that namespace gets in the way, leading to inability of finding
> the proper hfile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20530) Composition of backup directory containing namespace when restoring is different from the actual hfile location
[
https://issues.apache.org/jira/browse/HBASE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-20530:
--
Status: Patch Available (was: Open)
One more attempt.
> Composition of backup directory containing namespace when restoring is
> different from the actual hfile location
> ---
>
> Key: HBASE-20530
> URL: https://issues.apache.org/jira/browse/HBASE-20530
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Critical
> Attachments: HBASE-20530-v1.patch, HBASE-20530-v2.patch,
> HBASE-20530-v3.patch
>
>
> Here is partial listing of output from incremental backup:
> {code}
> 5306 2018-05-04 02:38
> hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/table_almphxih4u/cf1/5648501da7194783947bbf07b172f07e
> {code}
> When restoring, here is what HBackupFileSystem.getTableBackupDir returns:
> {code}
> fileBackupDir=hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/default/table_almphxih4u
> {code}
> You can see that namespace gets in the way, leading to inability of finding
> the proper hfile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20530) Composition of backup directory containing namespace when restoring is different from the actual hfile location
[
https://issues.apache.org/jira/browse/HBASE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-20530:
--
Release Note: There is a directory layout change (tables with default
namespace now get additional level in directory structure of the WALPlayer
output) for WALPlayer output in WAL - to- HFile conversion mode, but only when
multiple tables are specified (this is case only for backup module). The other
tools using WALPLayer are not affected (unless they use multiple tables mode
introduced by B&R feature). (was: There is a directory layout change (tables
with default namespace now get additional level in directory structure of the
WALPlayer output) for WALPlayer output in WAL - to- HFile conversion mode, but
only when multiple tables are specified (this is case only for backup module).
The other tools using WALPLayer are not affected.)
> Composition of backup directory containing namespace when restoring is
> different from the actual hfile location
> ---
>
> Key: HBASE-20530
> URL: https://issues.apache.org/jira/browse/HBASE-20530
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Vladimir Rodionov
>Priority: Critical
> Attachments: HBASE-20530-v1.patch, HBASE-20530-v2.patch,
> HBASE-20530-v3.patch
>
>
> Here is partial listing of output from incremental backup:
> {code}
> 5306 2018-05-04 02:38
> hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/table_almphxih4u/cf1/5648501da7194783947bbf07b172f07e
> {code}
> When restoring, here is what HBackupFileSystem.getTableBackupDir returns:
> {code}
> fileBackupDir=hdfs://mycluster/user/hbase/backup_loc/backup_1525401467793/default/table_almphxih4u
> {code}
> You can see that namespace gets in the way, leading to inability of finding
> the proper hfile.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20547) Restore from backup will fail if done from a different file system
[ https://issues.apache.org/jira/browse/HBASE-20547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-20547: -- Status: Patch Available (was: Open) Patch v1. > Restore from backup will fail if done from a different file system > -- > > Key: HBASE-20547 > URL: https://issues.apache.org/jira/browse/HBASE-20547 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Major > Attachments: HBASE-20547-v1.patch > > > In recent tests, restore from s3a:// to local hdfs:// fails with "not > supported file system". This is due to a bug in a code that creates instance > of a file system being restored from. > Credits: [~te...@apache.org], Gaurav Sharma -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20547) Restore from backup will fail if done from a different file system
[ https://issues.apache.org/jira/browse/HBASE-20547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-20547: -- Attachment: HBASE-20547-v1.patch > Restore from backup will fail if done from a different file system > -- > > Key: HBASE-20547 > URL: https://issues.apache.org/jira/browse/HBASE-20547 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Major > Attachments: HBASE-20547-v1.patch > > > In recent tests, restore from s3a:// to local hdfs:// fails with "not > supported file system". This is due to a bug in a code that creates instance > of a file system being restored from. > Credits: [~te...@apache.org], Gaurav Sharma -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20582) Bump up the Jackson and Jruby version because of some reported vulnerabilities
[
https://issues.apache.org/jira/browse/HBASE-20582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476394#comment-16476394
]
Hadoop QA commented on HBASE-20582:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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} 5m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
50s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
32s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
1s{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} xml {color} | {color:green} 0m
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 2s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
52s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}149m 4s{color}
| {color:red} root 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}203m 55s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.mapreduce.TestSyncTable |
| | hadoop.hbase.mapreduce.TestHashTable |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20582 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923358/HBASE-20582.patch |
| Optional Tests | asflicense javac javadoc unit shadedjars hadoopcheck
xml compile |
| uname | Linux 66b4f5797381 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 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 / 26babcf013 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12826/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12826/testReport/ |
| Max. process+thread count | 4595 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12826/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Bump up the Jackson and Jruby version because of some reported vulnerabilities
> --
>
> Key: HBASE-20582
> URL: https://issues.apache.org/jira/browse/HBASE-20582
>
[jira] [Created] (HBASE-20588) Space quota change after quota violation doesn't seem to take in effect
Biju Nair created HBASE-20588:
-
Summary: Space quota change after quota violation doesn't seem to
take in effect
Key: HBASE-20588
URL: https://issues.apache.org/jira/browse/HBASE-20588
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 2.0.0
Reporter: Biju Nair
Steps followed
- Through h{{base shell}}
{noformat}
set_quota TYPE => SPACE, TABLE => 'TestTable', LIMIT => '2M', POLICY =>
NO_INSERTS{noformat}
- Run {{PE}} until the quota is reached
{noformat}
hbase org.apache.hadoop.hbase.PerformanceEvaluation --nomapred --rows=2000
sequentialWrite 1{noformat}
- Through {{HBase}} shell
{noformat}
set_quota TYPE => SPACE, TABLE => 'TestTable', LIMIT => NONE{noformat}
- Through {{HBase}} shell verify the effective Quotas
{noformat}
> list_quotas
OWNER QUOTAS
0 row(s)
Took 0.0365 seconds{noformat}
- Wait for some time (at least 5 mins) and try to add data to the table
{noformat}
> put 'TestTable','r1','info:0','v1'
ERROR: org.apache.hadoop.hbase.quotas.SpaceLimitingException: NO_INSERTS Puts
are disallowed due to a space quota.
at
org.apache.hadoop.hbase.quotas.policies.NoInsertsViolationPolicyEnforcement.check(NoInsertsViolationPolicyEnforcement.java:47){noformat}
To resolve the issue, {{RSes}} need to be restarted which points to in memory
data not getting reset.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20447) Only fail cacheBlock if block collisions aren't related to next block metadata
[
https://issues.apache.org/jira/browse/HBASE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476417#comment-16476417
]
Hudson commented on HBASE-20447:
Results for branch branch-1.4
[build #321 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/321/]:
(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-1.4/321//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/321//JDK7_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-1.4/321//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Only fail cacheBlock if block collisions aren't related to next block metadata
> --
>
> Key: HBASE-20447
> URL: https://issues.apache.org/jira/browse/HBASE-20447
> Project: HBase
> Issue Type: Bug
> Components: BlockCache, BucketCache
>Affects Versions: 1.4.3, 2.0.0
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.4.5
>
> Attachments: HBASE-20447.branch-1.001.patch,
> HBASE-20447.branch-1.002.patch, HBASE-20447.branch-1.003.patch,
> HBASE-20447.branch-1.004.patch, HBASE-20447.branch-1.005.patch,
> HBASE-20447.branch-1.006.patch, HBASE-20447.master.001.patch,
> HBASE-20447.master.002.patch, HBASE-20447.master.003.patch,
> HBASE-20447.master.004.patch
>
>
> This is the issue I was originally having here:
> [http://mail-archives.apache.org/mod_mbox/hbase-dev/201802.mbox/%3CCAN+qs_Pav=md_aoj4xji+kcnetubg2xou2ntxv1g6m8-5vn...@mail.gmail.com%3E]
>
> When we pread, we don't force the read to read all of the next block header.
> However, when we get into a race condition where two opener threads try to
> cache the same block and one thread read all of the next block header and the
> other one didn't, it will fail the open process. This is especially important
> in a splitting case where it will potentially fail the split process.
> Instead, in the caches, we should only fail if the required blocks are
> different.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20547) Restore from backup will fail if done from a different file system
[
https://issues.apache.org/jira/browse/HBASE-20547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476426#comment-16476426
]
Hadoop QA commented on HBASE-20547:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
26s{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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} 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} 7m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
23s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
11s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{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} 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}
13m 2s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
12s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 11m
58s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 50m 33s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20547 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923542/HBASE-20547-v1.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 58ba309d596c 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 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 / 26babcf013 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12831/testReport/ |
| Max. process+thread count | 4181 (vs. ulimit of 1) |
| modules | C: hbase-backup U: hbase-backup |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12831/console |
| Pow
[jira] [Commented] (HBASE-20488) PE tool prints full name in help message
[
https://issues.apache.org/jira/browse/HBASE-20488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476427#comment-16476427
]
Hadoop QA commented on HBASE-20488:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{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} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
48s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
19s{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} 4m
47s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
15m 10s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 14m 0s{color}
| {color:red} hbase-mapreduce in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 53m 8s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.mapreduce.TestSyncTable |
| | hadoop.hbase.mapreduce.TestHashTable |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20488 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923534/HBASE-20488.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 99f94b5e506b 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9
14:43:09 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 / 26babcf013 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12830/artifact/patchprocess/patch-unit-hbase-mapreduce.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12830/testReport/ |
| Max. process+thread count | 4483 (vs. ulimit of 1) |
|
[jira] [Commented] (HBASE-20530) Composition of backup directory containing namespace when restoring is different from the actual hfile location
[
https://issues.apache.org/jira/browse/HBASE-20530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476457#comment-16476457
]
Hadoop QA commented on HBASE-20530:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 3m
19s{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 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
27s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
5s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{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} 4m
55s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
16m 13s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 19m 51s{color}
| {color:red} hbase-mapreduce in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 15m
21s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
25s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 83m 51s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.mapreduce.TestHashTable |
| | hadoop.hbase.mapreduce.TestSyncTable |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20530 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12923540/HBASE-20530-v3.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 4f4d40074db6 3.13.0-137-generic #186-Ubuntu SMP Mon Dec 4
19:09:19 UTC 2017 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 / 26babcf013 |
| maven |
[jira] [Commented] (HBASE-20463) Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL change and document"
[
https://issues.apache.org/jira/browse/HBASE-20463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476499#comment-16476499
]
Benoit Sigoure commented on HBASE-20463:
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code:java}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code}
{code:java}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
> Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL
> change and document"
> --
>
> Key: HBASE-20463
> URL: https://issues.apache.org/jira/browse/HBASE-20463
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 1.5.0, 1.4.4
>
> Attachments: HBASE-20463-branch-1.v0.patch, HBASE-20463.0.patch
>
>
> Hope you don't mind my making an issue for fixing branch-1 breakage [~busbey]
> (and [~apurtell]).
> See parent for discussion on breakage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20463) Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL change and document"
[
https://issues.apache.org/jira/browse/HBASE-20463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476499#comment-16476499
]
Benoit Sigoure edited comment on HBASE-20463 at 5/15/18 9:31 PM:
-
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code:java}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code:java}
{code:java}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
was (Author: tsuna):
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code:java}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code}
{code:java}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
> Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL
> change and document"
> --
>
> Key: HBASE-20463
> URL: https://issues.apache.org/jira/browse/HBASE-20463
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 1.5.0, 1.4.4
>
> Attachments: HBASE-20463-branch-1.v0.patch, HBASE-20463.0.patch
>
>
> Hope you don't mind my making an issue for fixing branch-1 breakage [~busbey]
> (and [~apurtell]).
> See parent for discussion on breakage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20463) Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL change and document"
[
https://issues.apache.org/jira/browse/HBASE-20463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476499#comment-16476499
]
Benoit Sigoure edited comment on HBASE-20463 at 5/15/18 9:31 PM:
-
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code:java}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code}
{code:java}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
was (Author: tsuna):
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code:java}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code}
{code:java}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
> Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL
> change and document"
> --
>
> Key: HBASE-20463
> URL: https://issues.apache.org/jira/browse/HBASE-20463
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 1.5.0, 1.4.4
>
> Attachments: HBASE-20463-branch-1.v0.patch, HBASE-20463.0.patch
>
>
> Hope you don't mind my making an issue for fixing branch-1 breakage [~busbey]
> (and [~apurtell]).
> See parent for discussion on breakage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20463) Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL change and document"
[
https://issues.apache.org/jira/browse/HBASE-20463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476499#comment-16476499
]
Benoit Sigoure edited comment on HBASE-20463 at 5/15/18 9:32 PM:
-
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code:java}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code:java}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
was (Author: tsuna):
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code}
{code}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
> Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL
> change and document"
> --
>
> Key: HBASE-20463
> URL: https://issues.apache.org/jira/browse/HBASE-20463
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 1.5.0, 1.4.4
>
> Attachments: HBASE-20463-branch-1.v0.patch, HBASE-20463.0.patch
>
>
> Hope you don't mind my making an issue for fixing branch-1 breakage [~busbey]
> (and [~apurtell]).
> See parent for discussion on breakage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20463) Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL change and document"
[
https://issues.apache.org/jira/browse/HBASE-20463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476499#comment-16476499
]
Benoit Sigoure edited comment on HBASE-20463 at 5/15/18 9:32 PM:
-
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code}
{code}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
was (Author: tsuna):
I'm still seeing the error with HBase 1.4.4 (I'm using the binary release
[here|http://www-us.apache.org/dist/hbase/1.4.4/hbase-1.4.4-bin.tar.gz])
{code:java}
foo@cc2a495eedfe:~$ java -version
openjdk version "9.0.4"
OpenJDK Runtime Environment (build 9.0.4+12-Debian-4)
OpenJDK 64-Bit Server VM (build 9.0.4+12-Debian-4, mixed mode){code}
{code:java}
{code:java}
foo@cc2a495eedfe:~$ /home/foo/hbase/bin/hbase shell
OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in
version 9.0 and will likely be removed in a future release.
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jruby.java.invokers.RubyToJavaInvoker
(file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar) to method
java.lang.Object.registerNatives()
WARNING: Please consider reporting this to the maintainers of
org.jruby.java.invokers.RubyToJavaInvoker
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
ArgumentError: wrong number of arguments (0 for 1)
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:10
method_added at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/javasupport/core_ext/object.rb:129
Pattern at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:2
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:1
require at org/jruby/RubyKernel.java:1062
(root) at
file:/home/foo/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.regex.rb:42
(root) at /home/foo/hbase/bin/../bin/hirb.rb:38
{code}
> Fix breakage introduced on branch-1 by HBASE-20276 "[shell] Revert shell REPL
> change and document"
> --
>
> Key: HBASE-20463
> URL: https://issues.apache.org/jira/browse/HBASE-20463
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 1.5.0, 1.4.4
>
> Attachments: HBASE-20463-branch-1.v0.patch, HBASE-20463.0.patch
>
>
> Hope you don't mind my making an issue for fixing branch-1 breakage [~busbey]
> (and [~apurtell]).
> See parent for discussion on breakage.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20571) JMXJsonServlet generates invalid JSON if it has NaN in metrics
[
https://issues.apache.org/jira/browse/HBASE-20571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476509#comment-16476509
]
Andrew Purtell commented on HBASE-20571:
Does this affect other versions than just 2.0.x?
> JMXJsonServlet generates invalid JSON if it has NaN in metrics
> --
>
> Key: HBASE-20571
> URL: https://issues.apache.org/jira/browse/HBASE-20571
> Project: HBase
> Issue Type: Bug
> Components: UI
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.0.1
>
> Attachments: HBASE-20571.branch-2.0.001.patch,
> HBASE-20571.branch-2.0.002.patch, HBASE-20571.branch-2.0.002.patch
>
>
> {{/jmx}} servlet responses invalid JSON, if some metrics are NaN:
> {code}
> "l1CacheHitCount" : 0,
> "l1CacheMissCount" : 0,
> "l1CacheHitRatio" : NaN,
> "l1CacheMissRatio" : NaN,
> "l2CacheHitCount" : 0,
> "l2CacheMissCount" : 0,
> "l2CacheHitRatio" : 0.0,
> "l2CacheMissRatio" : 0.0,
> {code}
> NaN is an invalid character sequence in JSON. We should not response NaN in
> metrics.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20564) Tighter ByteBufferKeyValue Cell Comparator
[ https://issues.apache.org/jira/browse/HBASE-20564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476512#comment-16476512 ] Ted Yu commented on HBASE-20564: Ran the addendum thru test suite which passed. > Tighter ByteBufferKeyValue Cell Comparator > -- > > Key: HBASE-20564 > URL: https://issues.apache.org/jira/browse/HBASE-20564 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.1 > > Attachments: 1.4.pe.write.0510.96203.cpu.svg, > 2.p3.write2.0514.104236.cpu.svg, 2.pe.write.135142.cpu.svg, 20564.addendum, > HBASE-20564.branch-2.0.001.patch, HBASE-20564.branch-2.0.002.patch, > HBASE-20564.branch-2.patch, hits.png > > > Comparing Cells in hbase2 takes almost 3x the CPU. > In hbase1, its a keyValue backed by a byte array caching a few important > values.. In hbase2, its a NoTagByteBufferChunkKeyValue(?) deserializing the > row/family/qualifier lengths repeatedly. > I tried making a purposed comparator -- one that was not generic -- and it > seemed to have a nicer profile coming close to hbase1 in percentage used > (I'll post graphs) when I ran it in my perpetual memstore filler (See scripts > attached to HBASE-20483). It doesn't work when I try to run it on cluster. > Let me run unit tests to see if it can figure what I have wrong. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20555) Backport HBASE-18083 and related changes in branch-1
[ https://issues.apache.org/jira/browse/HBASE-20555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476557#comment-16476557 ] Tak Lon (Stephen) Wu commented on HBASE-20555: -- sorry that this is the first time I requested a large backport from branch-2 to branch-1, do I need to follow any other regular process ? > Backport HBASE-18083 and related changes in branch-1 > > > Key: HBASE-20555 > URL: https://issues.apache.org/jira/browse/HBASE-20555 > Project: HBase > Issue Type: Umbrella > Components: HFile, snapshots >Affects Versions: 1.4.4, 1.4.5 >Reporter: Tak Lon (Stephen) Wu >Assignee: Tak Lon (Stephen) Wu >Priority: Major > > This will be the umbrella JIRA for backporting HBASE-18083 of `Make > large/small file clean thread number configurable in HFileCleaner` from > HBase's branch-2 to HBase's branch-1 that will needs a total of 4 sub-tasks > that backport HBASE-16490, HBASE-17215, HBASE-17854 and then HBASE-18083 > The goal is to improve HFile cleaning performance that has been introduced in > branch-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20555) Backport HBASE-18083 and related changes in branch-1
[ https://issues.apache.org/jira/browse/HBASE-20555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476557#comment-16476557 ] Tak Lon (Stephen) Wu edited comment on HBASE-20555 at 5/15/18 10:25 PM: This is the first time I requested a large backport from branch-2 to branch-1, do I need to follow any other regular process ? was (Author: taklwu): sorry that this is the first time I requested a large backport from branch-2 to branch-1, do I need to follow any other regular process ? > Backport HBASE-18083 and related changes in branch-1 > > > Key: HBASE-20555 > URL: https://issues.apache.org/jira/browse/HBASE-20555 > Project: HBase > Issue Type: Umbrella > Components: HFile, snapshots >Affects Versions: 1.4.4, 1.4.5 >Reporter: Tak Lon (Stephen) Wu >Assignee: Tak Lon (Stephen) Wu >Priority: Major > > This will be the umbrella JIRA for backporting HBASE-18083 of `Make > large/small file clean thread number configurable in HFileCleaner` from > HBase's branch-2 to HBase's branch-1 that will needs a total of 4 sub-tasks > that backport HBASE-16490, HBASE-17215, HBASE-17854 and then HBASE-18083 > The goal is to improve HFile cleaning performance that has been introduced in > branch-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20555) Backport HBASE-18083 and related changes in branch-1
[ https://issues.apache.org/jira/browse/HBASE-20555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476557#comment-16476557 ] Tak Lon (Stephen) Wu edited comment on HBASE-20555 at 5/15/18 10:30 PM: This is the first time I requested a large backport from branch-2 to branch-1, do I need to follow any other regular process ? I was thinking to submit these patches in the sequential order, because they depend on each other. was (Author: taklwu): This is the first time I requested a large backport from branch-2 to branch-1, do I need to follow any other regular process ? > Backport HBASE-18083 and related changes in branch-1 > > > Key: HBASE-20555 > URL: https://issues.apache.org/jira/browse/HBASE-20555 > Project: HBase > Issue Type: Umbrella > Components: HFile, snapshots >Affects Versions: 1.4.4, 1.4.5 >Reporter: Tak Lon (Stephen) Wu >Assignee: Tak Lon (Stephen) Wu >Priority: Major > > This will be the umbrella JIRA for backporting HBASE-18083 of `Make > large/small file clean thread number configurable in HFileCleaner` from > HBase's branch-2 to HBase's branch-1 that will needs a total of 4 sub-tasks > that backport HBASE-16490, HBASE-17215, HBASE-17854 and then HBASE-18083 > The goal is to improve HFile cleaning performance that has been introduced in > branch-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20548) Master fails to startup on large clusters, refreshing block distribution
[ https://issues.apache.org/jira/browse/HBASE-20548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476568#comment-16476568 ] Andrew Purtell commented on HBASE-20548: > My proposal is to refresh HDFS block distribution at the end of master > initialization and not at retainAssignment()'s createCluster(). I think this makes sense. Reasonable to say that O(region) or O(file) tasks shouldn't block initialization, even if done in parallel. Schedule it or start it in the background. > Master fails to startup on large clusters, refreshing block distribution > > > Key: HBASE-20548 > URL: https://issues.apache.org/jira/browse/HBASE-20548 > Project: HBase > Issue Type: Improvement >Affects Versions: 1.4.4 >Reporter: Thiruvel Thirumoolan >Assignee: Thiruvel Thirumoolan >Priority: Major > Fix For: 1.5.0, 1.4.5 > > > On our large clusters with, master has failed to startup within specified > time and aborted itself since it was initializing HDFS block distribution. > Enable table also takes time for larger tables for the same reason. My > proposal is to refresh HDFS block distribution at the end of master > initialization and not at retainAssignment()'s createCluster(). This would > address HBASE-16570's intention, but avoid the problems we ran into. > cc [~aoxiang] [~tedyu] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20500) [rsgroup] should keep at least one server in default group
[ https://issues.apache.org/jira/browse/HBASE-20500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16476570#comment-16476570 ] Andrew Purtell commented on HBASE-20500: Does this affect RSgroups in branch-1 too? > [rsgroup] should keep at least one server in default group > -- > > Key: HBASE-20500 > URL: https://issues.apache.org/jira/browse/HBASE-20500 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0 >Reporter: Yechao Chen >Assignee: Yechao Chen >Priority: Major > Fix For: 3.0.0, 2.1.0 > > Attachments: HBASE-20500-branch-2.v1.patch, > HBASE-20500-master.v1.patch, HBASE-20500-master.v2.patch, > HBASE-20500-master.v3.patch, HBASE-20500-master.v4.patch, > HBASE-20500-master.v5.patch > > > we move all the servers from default group > the default group will has no servers, > then we create a new table , > it will failed case of the default group has no servers > eorr info is : > EROOR: ConstraintException:Target RSGroup must have at lease on server > > we should keep at least one server in 'default' RSGroup > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
