[jira] [Commented] (HBASE-20095) Redesign single instance pool in CleanerChore
[
https://issues.apache.org/jira/browse/HBASE-20095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415143#comment-16415143
]
Hadoop QA commented on HBASE-20095:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
2s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.7.0/precommit-patchnames for
instructions. {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} 5m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
35s{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
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{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
46s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 19s{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
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}115m 54s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}163m 52s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20095 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916332/20095.addendum-2.txt |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2e035f024b5e 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@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 056c3395d9 |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| unit |
https:/
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415148#comment-16415148
]
Peter Somogyi commented on HBASE-20292:
---
+1
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota reassigned HBASE-20253:
--
Assignee: Gabor Bota
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Somogyi updated HBASE-20292:
--
Resolution: Fixed
Fix Version/s: 2.0.0
1.4.4
1.3.3
1.2.7
1.5.0
2.1.0
3.0.0
Status: Resolved (was: Patch Available)
Thanks [~brfrn169], pushed to all branches.
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20293) get_splits returns duplicate split points when region replication is on
Toshihiro Suzuki created HBASE-20293:
Summary: get_splits returns duplicate split points when region
replication is on
Key: HBASE-20293
URL: https://issues.apache.org/jira/browse/HBASE-20293
Project: HBase
Issue Type: Bug
Reporter: Toshihiro Suzuki
Assignee: Toshihiro Suzuki
When region replication is on, get_splits returns duplicate split points like
the following:
{code}
hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
["10"]
Created table test
Took 1.0975 seconds
hbase(main):002:0> get_splits "test"
Total number of splits = 4
10
10
10
Took 0.0941 seconds
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-20292:
-
Priority: Trivial (was: Major)
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415171#comment-16415171
]
Toshihiro Suzuki commented on HBASE-20292:
--
Thank you [~psomogyi].
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-20293:
-
Component/s: shell
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415175#comment-16415175
]
Hudson commented on HBASE-20292:
SUCCESS: Integrated in Jenkins build HBase-1.3-IT #383 (See
[https://builds.apache.org/job/HBase-1.3-IT/383/])
HBASE-20292 Wrong URLs in the descriptions for update_all_config and (psomogyi:
rev 3791d2e20dc9fcd500f80f1efbc99571193b55f6)
* (edit) hbase-shell/src/main/ruby/shell/commands/update_config.rb
* (edit) hbase-shell/src/main/ruby/shell/commands/update_all_config.rb
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415182#comment-16415182
]
Hudson commented on HBASE-20292:
SUCCESS: Integrated in Jenkins build HBase-1.2-IT #1093 (See
[https://builds.apache.org/job/HBase-1.2-IT/1093/])
HBASE-20292 Wrong URLs in the descriptions for update_all_config and (psomogyi:
rev 130f832463d2727b081d08451e75a6087968a40d)
* (edit) hbase-shell/src/main/ruby/shell/commands/update_all_config.rb
* (edit) hbase-shell/src/main/ruby/shell/commands/update_config.rb
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-20293:
-
Attachment: HBASE-20293.master.001.patch
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[ https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20191: -- Summary: Cleanup replication barrier and last pushed sequence id when deleting table (was: Cleanup replication barrier for delete table in the chore) > Cleanup replication barrier and last pushed sequence id when deleting table > --- > > Key: HBASE-20191 > URL: https://issues.apache.org/jira/browse/HBASE-20191 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[ https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20191: -- Fix Version/s: 3.0.0 > Cleanup replication barrier and last pushed sequence id when deleting table > --- > > Key: HBASE-20191 > URL: https://issues.apache.org/jira/browse/HBASE-20191 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20191.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[ https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20191: -- Component/s: Replication > Cleanup replication barrier and last pushed sequence id when deleting table > --- > > Key: HBASE-20191 > URL: https://issues.apache.org/jira/browse/HBASE-20191 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20191.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[ https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20191: -- Attachment: HBASE-20191.patch > Cleanup replication barrier and last pushed sequence id when deleting table > --- > > Key: HBASE-20191 > URL: https://issues.apache.org/jira/browse/HBASE-20191 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20191.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20095) Redesign single instance pool in CleanerChore
[ https://issues.apache.org/jira/browse/HBASE-20095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415192#comment-16415192 ] Ted Yu commented on HBASE-20095: The test failure was for load balancer which was not related to addendum. [~mdrob]: Can you take a look at the addendum too ? > Redesign single instance pool in CleanerChore > - > > Key: HBASE-20095 > URL: https://issues.apache.org/jira/browse/HBASE-20095 > Project: HBase > Issue Type: Improvement >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Critical > Fix For: 3.0.0, 2.1.0 > > Attachments: 20095.addendum, 20095.addendum-2.txt, > HBASE-20095.master.001.patch, HBASE-20095.master.002.patch, > HBASE-20095.master.003.patch, HBASE-20095.master.004.patch, > HBASE-20095.master.005.patch, HBASE-20095.master.006.patch, > HBASE-20095.master.007.patch, HBASE-20095.master.008.patch, > HBASE-20095.master.009.patch, HBASE-20095.master.010.patch, > HBASE-20095.master.011.patch, HBASE-20095.master.012.patch, > HBASE-20095.master.013.patch, HBASE-20095.master.014.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415198#comment-16415198
]
Toshihiro Suzuki commented on HBASE-20293:
--
I just attached a patch for this issue. I made _get_splits_internal() return
splits only for default replica.
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[ https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20191: -- Status: Patch Available (was: Open) > Cleanup replication barrier and last pushed sequence id when deleting table > --- > > Key: HBASE-20191 > URL: https://issues.apache.org/jira/browse/HBASE-20191 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20191.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20159) Support using separate ZK quorums for client
[
https://issues.apache.org/jira/browse/HBASE-20159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415199#comment-16415199
]
Reid Chan commented on HBASE-20159:
---
Hi Yu,
May i ask what will happen in following two cases, {{(clientQuorumServers !=
null && clientZkObserverMode is true)}} or {{(clientQuorumServers == null &&
clientZkObserverMode is true)}}.
>From patch, it looks like remain the same? or do these count as
>mis-configuration?
> Support using separate ZK quorums for client
>
>
> Key: HBASE-20159
> URL: https://issues.apache.org/jira/browse/HBASE-20159
> Project: HBase
> Issue Type: New Feature
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Major
> Attachments: HBASE-20159.patch, HBASE-20159.v2.patch,
> HBASE-20159.v3.patch
>
>
> Currently we are using the same zookeeper quorums for client and server,
> which makes us under risk that if some client connection boost exhausted
> zookeeper, RegionServer might abort due to zookeeper session loss. Actually
> we have suffered from this many times in production.
> Here we propose to allow client to use different ZK quorums, through below
> settings:
> {noformat}
> hbase.client.zookeeper.quorum
> hbase.client.zookeeper.property.clientPort
> hbase.client.zookeeper.observer.mode
> {noformat}
> The first two are for specifying client zookeeper properties, and the third
> one indicating whether the client ZK nodes are in observer mode. If the
> client ZK are not observer nodes, HMaster will take responsibility to
> synchronize necessary meta information (such as meta location and master
> address, etc.) from server to client ZK
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20229) ConnectionImplementation.locateRegions() returns duplicated entries when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415203#comment-16415203
]
Hadoop QA commented on HBASE-20229:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
42s{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:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
49s{color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
9s{color} | {color:red} hbase-client in branch-1 failed with JDK v1.8.0_163.
{color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
15s{color} | {color:red} hbase-server in branch-1 failed with JDK v1.8.0_163.
{color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
11s{color} | {color:red} hbase-client in branch-1 failed with JDK v1.7.0_171.
{color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
17s{color} | {color:red} hbase-server in branch-1 failed with JDK v1.7.0_171.
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
55s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
3s{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
56s{color} | {color:green} branch-1 passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
7s{color} | {color:green} branch-1 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
53s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
10s{color} | {color:red} hbase-client in the patch failed with JDK v1.8.0_163.
{color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
20s{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_163.
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 10s{color}
| {color:red} hbase-client in the patch failed with JDK v1.8.0_163. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 20s{color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_163. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
12s{color} | {color:red} hbase-client in the patch failed with JDK v1.7.0_171.
{color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
22s{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_171.
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 12s{color}
| {color:red} hbase-client in the patch failed with JDK v1.7.0_171. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 22s{color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_171. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s{color} | {color:green} The patch hbase-client passed checkstyle {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s{color} | {color:green} hbase-server: The patch generated 0 new + 0
unchanged - 1 fixed = 0 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} 2m
47s{color} |
[jira] [Commented] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[ https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415211#comment-16415211 ] Duo Zhang commented on HBASE-20191: --- Not sure whether this is the correct way. Since for a deleted table, we still need to replicate its edits... Leave the patch here and let me think more... > Cleanup replication barrier and last pushed sequence id when deleting table > --- > > Key: HBASE-20191 > URL: https://issues.apache.org/jira/browse/HBASE-20191 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20191.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toshihiro Suzuki updated HBASE-20293:
-
Status: Patch Available (was: Open)
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20294) Also cleanup last pushed sequence id in ReplicationBarrierCleaner
Duo Zhang created HBASE-20294: - Summary: Also cleanup last pushed sequence id in ReplicationBarrierCleaner Key: HBASE-20294 URL: https://issues.apache.org/jira/browse/HBASE-20294 Project: HBase Issue Type: Sub-task Components: Replication Reporter: Duo Zhang Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20293) get_splits returns duplicate split points when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415246#comment-16415246
]
Hadoop QA commented on HBASE-20293:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{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: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} master Compile Tests {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} 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} 5m
7s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 17 new + 452 unchanged - 2 fixed =
469 total (was 454) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
15s{color} | {color:red} The patch generated 9 new + 472 unchanged - 0 fixed =
481 total (was 472) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
11s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
38s{color} | {color:green} hbase-shell 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} 19m 14s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20293 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916353/HBASE-20293.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 9d9f82c469ad 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@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 2a2258656b |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| rubocop | v0.54.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/12166/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/12166/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12166/testReport/ |
| Max. process+thread count | 2153 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12166/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> get_splits returns duplicate split points when region replication is on
> ---
>
> Key: HBASE-20293
> URL: https://issues.apache.org/jira/browse/HBASE-20293
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Attachments: HBASE-20293.master.001.patch
>
>
> When region replication is on, get_splits returns duplicate split points like
> the following:
> {code}
> hbase(main):001:0> create "test", "cf", {REGION_REPLICATION => 3}, SPLITS =>
> ["10"]
> Created table test
> Took 1.0975 seconds
> hbase(main):002:0> get_splits "test"
> Total number of splits = 4
> 10
> 10
> 10
> Took 0.0941 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled
[ https://issues.apache.org/jira/browse/HBASE-20280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415300#comment-16415300 ] Anoop Sam John commented on HBASE-20280: The new fix of reopen channel making the possible dead lock right? The above exception u see with out even that fix (Reopen closed channel)? > Fix possibility of deadlocking in refreshFileConnections when prefetch is > enabled > - > > Key: HBASE-20280 > URL: https://issues.apache.org/jira/browse/HBASE-20280 > Project: HBase > Issue Type: Bug > Components: BucketCache >Affects Versions: 2.0.0-beta-2, 1.4.2 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Attachments: HBASE-20280.master.001.patch > > > When prefetch on open is specified, there is a deadlocking case > where if the prefetch is cancelled, the PrefetchExecutor interrupts > the threads if necessary, when that happens in FileIOEngine, it > causes an ClosedByInterruptException which is a subclass of > ClosedChannelException. If we retry all ClosedChannelExceptions, > this will lock as this access is expected to be interrupted. > This change removes calling refreshFileConnections for > ClosedByInterruptExceptions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20250) Heartbeat checks are not working when using row filter
[
https://issues.apache.org/jira/browse/HBASE-20250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
park junhyeok updated HBASE-20250:
--
Affects Version/s: 2.0.0
> Heartbeat checks are not working when using row filter
> --
>
> Key: HBASE-20250
> URL: https://issues.apache.org/jira/browse/HBASE-20250
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 1.2.6, 2.0.0
>Reporter: park junhyeok
>Priority: Minor
>
> If you use a row filter and the filter removes all cells, loop inside
> HRegion#nextInternal do not check time limit.
>
> {code:java}
> if (hasFilterRow) {
> if (LOG.isTraceEnabled()) {
> LOG.trace("filter#hasFilterRow is true which prevents partial results from
> being "
> + " formed. Changing scope of limits that may create partials");
> }
> scannerContext.setSizeLimitScope(LimitScope.BETWEEN_ROWS);
> scannerContext.setTimeLimitScope(LimitScope.BETWEEN_ROWS);
> }
> {code}
>
>
> The scan continues until find valid cell without hearbeat message.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota updated HBASE-20253:
---
Attachment: HBASE-20253.master.001.patch
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota updated HBASE-20253:
---
Status: Patch Available (was: Open)
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415375#comment-16415375
]
Hadoop QA commented on HBASE-20253:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @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
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
12s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
49s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
8s{color} | {color:red} The patch generated 3 new + 386 unchanged - 1 fixed =
389 total (was 387) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
3s{color} | {color:red} The patch generated 3 new + 723 unchanged - 0 fixed =
726 total (was 723) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
13s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
58s{color} | {color:green} hbase-shell 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} 20m 20s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20253 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916368/HBASE-20253.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 1beea7b5ec4e 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@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 2a2258656b |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| rubocop | v0.54.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/12167/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/12167/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12167/testReport/ |
| Max. process+thread count | 2208 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12167/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from sna
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415396#comment-16415396
]
Hudson commented on HBASE-20292:
Results for branch branch-1
[build #262 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/262/]:
(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/262//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/262//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/262//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20111) Able to split region explicitly even on shouldSplit return false from split policy
[ https://issues.apache.org/jira/browse/HBASE-20111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajeshbabu Chintaguntla updated HBASE-20111: Attachment: HBASE-20111_v3.patch > Able to split region explicitly even on shouldSplit return false from split > policy > -- > > Key: HBASE-20111 > URL: https://issues.apache.org/jira/browse/HBASE-20111 > Project: HBase > Issue Type: Bug >Reporter: Rajeshbabu Chintaguntla >Assignee: Rajeshbabu Chintaguntla >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-20111.001.branch-2.0.patch, HBASE-20111.patch, > HBASE-20111_test.patch, HBASE-20111_v2.patch, HBASE-20111_v3.patch > > > Currently able to split the region explicitly even when the split policy > returns from shouldSplit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20111) Able to split region explicitly even on shouldSplit return false from split policy
[ https://issues.apache.org/jira/browse/HBASE-20111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415405#comment-16415405 ] Rajeshbabu Chintaguntla commented on HBASE-20111: - bq.Don't you want this to be: !(info.isMetaRegion() || TableName.NAMESPACE_TABLE_NAME.equals(info.getTable()))? The part of the conditional will never be true because isMetaRegion is only true for the hbase:meta table. Yes [~elserj] it's my blunder. Now in the patch just checking for meta only to not split anytime. [~stack] can you confirm whether we can allow splitting namespace or not as Josh mentioned in the above comment. If it's ok to split the namespace then I can commit this patch. > Able to split region explicitly even on shouldSplit return false from split > policy > -- > > Key: HBASE-20111 > URL: https://issues.apache.org/jira/browse/HBASE-20111 > Project: HBase > Issue Type: Bug >Reporter: Rajeshbabu Chintaguntla >Assignee: Rajeshbabu Chintaguntla >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-20111.001.branch-2.0.patch, HBASE-20111.patch, > HBASE-20111_test.patch, HBASE-20111_v2.patch, HBASE-20111_v3.patch > > > Currently able to split the region explicitly even when the split policy > returns from shouldSplit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[
https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415428#comment-16415428
]
Hadoop QA commented on HBASE-20191:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
41s{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
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
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} 5m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
22s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s{color} | {color:green} The patch hbase-protocol-shaded passed checkstyle
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
30s{color} | {color:green} hbase-client: The patch generated 0 new + 64
unchanged - 1 fixed = 64 total (was 65) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
11s{color} | {color:red} hbase-replication: The patch generated 1 new + 3
unchanged - 0 fixed = 4 total (was 3) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
10s{color} | {color:red} hbase-server: The patch generated 2 new + 13 unchanged
- 38 fixed = 15 total (was 51) {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
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}
19m 37s{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} hbaseprotoc {color} | {color:green}
1m 36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
30s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
55s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
22s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:red}-1{color
[jira] [Created] (HBASE-20295) TableOutputFormat.checkOutputSpecs throw NullPointerException Exception
Michael Jin created HBASE-20295:
---
Summary: TableOutputFormat.checkOutputSpecs throw
NullPointerException Exception
Key: HBASE-20295
URL: https://issues.apache.org/jira/browse/HBASE-20295
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 1.4.0
Environment: Spark 2.2.1, HBase 1.4.0
Reporter: Michael Jin
I am using spark write data to HBase by using RDD.
saveAsNewAPIHadoopDataset function, it works fine with hbase 1.3.1, but when
update my hbase dependency to 1.4.0 in pom.xml, it throw
java.lang.NullPointerException, it is caused by a logic error in
TableOutputFormat.checkOutputSpecs function, please check below details:
first let's take a look at SparkHadoopMapReduceWriter.write function in
SparkHadoopMapReduceWriter.scala
{code:java}
// SparkHadoopMapReduceWriter.write
(org.apache.spark.internal.io.SparkHadoopMapReduceWriter.scala)
def write[K, V: ClassTag](
rdd: RDD[(K, V)],
hadoopConf: Configuration): Unit = {
// Extract context and configuration from RDD.
val sparkContext = rdd.context
val stageId = rdd.id
val sparkConf = rdd.conf
val conf = new SerializableConfiguration(hadoopConf)
// Set up a job.
val jobTrackerId = SparkHadoopWriterUtils.createJobTrackerID(new Date())
val jobAttemptId = new TaskAttemptID(jobTrackerId, stageId, TaskType.MAP, 0,
0)
val jobContext = new TaskAttemptContextImpl(conf.value, jobAttemptId)
val format = jobContext.getOutputFormatClass
if (SparkHadoopWriterUtils.isOutputSpecValidationEnabled(sparkConf)) {
// FileOutputFormat ignores the filesystem parameter
val jobFormat = format.newInstance
jobFormat.checkOutputSpecs(jobContext)
}
val committer = FileCommitProtocol.instantiate(
className = classOf[HadoopMapReduceCommitProtocol].getName,
jobId = stageId.toString,
outputPath = conf.value.get("mapreduce.output.fileoutputformat.outputdir"),
isAppend = false).asInstanceOf[HadoopMapReduceCommitProtocol]
committer.setupJob(jobContext)
...{code}
in "write" function if output spec validation is enabled, it will call
checkOutputSpec function in TableOutputFormat class, but the job format is
simply created by "vall jobFormat = format.newInstance", this will NOT
initialize "conf" member variable in TableOutputFormat class, let's continue
check checkOutputSpecs function in TableOutputFormat class
{code:java}
// TableOutputFormat.checkOutputSpecs
(org.apache.hadoop.hbase.mapreduce.TableOutputFormat.java) HBASE 1.4.0
@Override
public void checkOutputSpecs(JobContext context) throws IOException,
InterruptedException {
try (Admin admin = ConnectionFactory.createConnection(getConf()).getAdmin()) {
TableName tableName = TableName.valueOf(this.conf.get(OUTPUT_TABLE));
if (!admin.tableExists(tableName)) {
throw new TableNotFoundException("Can't write, table does not exist:" +
tableName.getNameAsString());
}
if (!admin.isTableEnabled(tableName)) {
throw new TableNotEnabledException("Can't write, table is not enabled: " +
tableName.getNameAsString());
}
}
}
{code}
"ConnectionFactory.createConnection(getConf())", as mentioned above "conf"
class member is not initialized, so getConf() will return null, so in the next
UserProvider create instance process, it throw the NullPointException(Please
part of stack trace at the end), it is a little confused that, context passed
by function parameter is actually been properly constructed, and it contains
Configuration object, why context is never used? So I suggest to use below code
to partly fix this issue:
{code:java}
// code placeholder
@Override
public void checkOutputSpecs(JobContext context) throws IOException,
InterruptedException {
Configuration hConf = context.getConfiguration();
if(hConf == null)
hConf = this.conf;
try (Admin admin = ConnectionFactory.createConnection(hConf).getAdmin()) {
TableName tableName = TableName.valueOf(hConf.get(OUTPUT_TABLE));
if (!admin.tableExists(tableName)) {
throw new TableNotFoundException("Can't write, table does not exist:" +
tableName.getNameAsString());
}
if (!admin.isTableEnabled(tableName)) {
throw new TableNotEnabledException("Can't write, table is not enabled: " +
tableName.getNameAsString());
}
}
}
{code}
In hbase 1.3.1, this issue is not exists because checkOutputSpecs has a blank
function body
Part of stack trace:
Exception in thread "main" java.lang.NullPointerException
at
org.apache.hadoop.hbase.security.UserProvider.instantiate(UserProvider.java:122)
at
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:214)
at
org.apache.hadoop.hbase.client.ConnectionFactory.createConnection(ConnectionFactory.java:119)
at
org.apache.hadoop.hbase.mapreduce.TableOutputFormat.che
[jira] [Commented] (HBASE-20289) Comparator for NormalizationPlan breaks comparator's convention
[
https://issues.apache.org/jira/browse/HBASE-20289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415517#comment-16415517
]
Hudson commented on HBASE-20289:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Comparator for NormalizationPlan breaks comparator's convention
> ---
>
> Key: HBASE-20289
> URL: https://issues.apache.org/jira/browse/HBASE-20289
> Project: HBase
> Issue Type: Bug
> Components: master
>Reporter: Yuki Tawara
>Assignee: Yuki Tawara
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20289.master.001.patch
>
>
> Comparator must meet the condition: sign(comparator(plan1, plan2)) = -
> sign(comparator(plan2, plan1)).
> Current implementation breaks above condition.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20288) [DOC] upgrade section needs to call out DLR
[
https://issues.apache.org/jira/browse/HBASE-20288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415518#comment-16415518
]
Hudson commented on HBASE-20288:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> [DOC] upgrade section needs to call out DLR
> ---
>
> Key: HBASE-20288
> URL: https://issues.apache.org/jira/browse/HBASE-20288
> Project: HBase
> Issue Type: Sub-task
> Components: documentation, wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: HBASE-20288.0.patch
>
>
> copied out of HBASE-13428. I think from [~stack]
> {quote}
> * Make sure Distributed Log Replay is not enabled on your hbase1 cluster; it
> was problematic in hbase1 and does not work at all in hbase2.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20130) Use defaults (16020 & 16030) as base ports when the RS is bound to localhost
[
https://issues.apache.org/jira/browse/HBASE-20130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415516#comment-16415516
]
Hudson commented on HBASE-20130:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Use defaults (16020 & 16030) as base ports when the RS is bound to localhost
>
>
> Key: HBASE-20130
> URL: https://issues.apache.org/jira/browse/HBASE-20130
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Umesh Agashe
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: hbase-20130.master.001.patch,
> hbase-20130.master.002.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19258) IntegrationTest for Backup and Restore
[
https://issues.apache.org/jira/browse/HBASE-19258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415520#comment-16415520
]
Hudson commented on HBASE-19258:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> IntegrationTest for Backup and Restore
> --
>
> Key: HBASE-19258
> URL: https://issues.apache.org/jira/browse/HBASE-19258
> Project: HBase
> Issue Type: Test
> Components: integration tests
>Reporter: Josh Elser
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Fix For: 3.0.0
>
> Attachments: 19258.v3.patch, HBASE-19258.v1.patch,
> HBASE-19258.v2.patch, HBASE-19258.v3.patch, HBASE-19258.v4.patch
>
>
> See chatter at https://docs.google.com/document/d/1xbPlLKjOcPq2LDqjbSkF6uND
> AG0mzgOxek6P3POLeMc/edit?usp=sharing
> We need to get an IntegrationTest in place for backup and restore.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20224) Web UI is broken in standalone mode
[
https://issues.apache.org/jira/browse/HBASE-20224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415515#comment-16415515
]
Hudson commented on HBASE-20224:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Web UI is broken in standalone mode
> ---
>
> Key: HBASE-20224
> URL: https://issues.apache.org/jira/browse/HBASE-20224
> Project: HBase
> Issue Type: Bug
> Components: UI, Usability
>Affects Versions: 2.0.0-beta-2
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments:
> 0001-HBASE-20224-Web-UI-is-broken-in-standalone-mode-ADDE.ADDENDUM.patch,
> 20224-addendum.3.txt, hbase-20224.master.001.patch,
> hbase-20224.master.002.patch, hbase-20224.master.003.patch,
> hbase-20224.master.addendum.patch
>
>
> Web UI doesn't show up in standalone mode on default port. This can be seen
> on master and branch-2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415523#comment-16415523
]
Hudson commented on HBASE-20292:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20260) Purge old content from the book for branch-2/master
[
https://issues.apache.org/jira/browse/HBASE-20260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415512#comment-16415512
]
Hudson commented on HBASE-20260:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Purge old content from the book for branch-2/master
> ---
>
> Key: HBASE-20260
> URL: https://issues.apache.org/jira/browse/HBASE-20260
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 2.0.0-beta-2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20260.ADDENDUM.patch, HBASE-20260.patch,
> HBASE-20260.v2.patch, HBASE-20260.v3.patch
>
>
> there's lots of old content that we should clean up to make room for new
> content. old warnings that don't matter any more, properties that don't
> exist, etc...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-20296) Remove replication barrier and last pushed sequence ids when removing from a peer
Duo Zhang created HBASE-20296: - Summary: Remove replication barrier and last pushed sequence ids when removing from a peer Key: HBASE-20296 URL: https://issues.apache.org/jira/browse/HBASE-20296 Project: HBase Issue Type: Sub-task Components: Replication Reporter: Duo Zhang Assignee: Duo Zhang Fix For: 3.0.0 Discussed with [~zghaobac] and [~openinx] offline, this is the only safe thing to do for now. It is not safe to remove barriers and last pushed sequence ids when deleting a table since we may still have edits which should be replicated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20229) ConnectionImplementation.locateRegions() returns duplicated entries when region replication is on
[
https://issues.apache.org/jira/browse/HBASE-20229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415519#comment-16415519
]
Hudson commented on HBASE-20229:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> ConnectionImplementation.locateRegions() returns duplicated entries when
> region replication is on
> -
>
> Key: HBASE-20229
> URL: https://issues.apache.org/jira/browse/HBASE-20229
> Project: HBase
> Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20229.branch-1.001.patch,
> HBASE-20229.branch-1.002.patch, HBASE-20229.master.001.patch,
> HBASE-20229.master.002.patch, HBASE-20229.master.003.patch,
> HBASE-20229.master.004.patch
>
>
> The issue is when region replication is on,
> ConnectionImplementation.locateRegions() returns duplicated entries.
> In the test in my patch, the table should have 1 primary region + 2
> secondaries, but ConnectionImplementation.locateRegions() returns 9 regions.
> Every region repeats 3 times (3 = replicas count).
> I think this is because the following code calls locateRegion() even for
> replica regions and then the result triples.
> {code:java}
> for (RegionInfo regionInfo : regions) {
> RegionLocations list = locateRegion(tableName,
> regionInfo.getStartKey(), useCache, true);
> if (list != null) {
> for (HRegionLocation loc : list.getRegionLocations()) {
> if (loc != null) {
> locations.add(loc);
> }
> }
> }
> {code}
> The fix in my patch is to make it call locateRegion() only for a primary
> region.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20254) Incorrect help message for merge_region
[
https://issues.apache.org/jira/browse/HBASE-20254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415514#comment-16415514
]
Hudson commented on HBASE-20254:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Incorrect help message for merge_region
> ---
>
> Key: HBASE-20254
> URL: https://issues.apache.org/jira/browse/HBASE-20254
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Minor
> Fix For: 3.0.0, 2.1.0, 2.0.0
>
> Attachments: HBASE-20254.master.001.patch,
> HBASE-20254.master.001.patch, HBASE-20254.master.002.patch,
> HBASE-20254.master.003.patch
>
>
> In 2.0 merge_region command accepts full region name not just the encoded
> region name but the help says only encoded can be used. The move command only
> accepts encoded region name.
>
> hbase(main):003:0> help 'merge_region'
> Merge two regions. Passing 'true' as the optional third parameter will force
> a merge ('force' merges regardless else merge will fail unless passed
> adjacent regions. 'force' is for expert use only).
>
> NOTE: You must pass the encoded region name, not the full region name so
> this command is a little different from other region operations. The encoded
> region name is the hash suffix on region names: e.g. if the region name were
> TestTable,0094429456,1289497600452.527db22f95c8a9e0116f0cc13c680396. then
> the encoded region name portion is 527db22f95c8a9e0116f0cc13c680396
>
> Examples:
>
> hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME'
> hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME', true
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20127) Add UT for serial replication after failover
[
https://issues.apache.org/jira/browse/HBASE-20127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415509#comment-16415509
]
Hudson commented on HBASE-20127:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Add UT for serial replication after failover
>
>
> Key: HBASE-20127
> URL: https://issues.apache.org/jira/browse/HBASE-20127
> Project: HBase
> Issue Type: Sub-task
> Components: Replication, test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20127-v1.patch, HBASE-20127.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20095) Redesign single instance pool in CleanerChore
[
https://issues.apache.org/jira/browse/HBASE-20095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415513#comment-16415513
]
Hudson commented on HBASE-20095:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Redesign single instance pool in CleanerChore
> -
>
> Key: HBASE-20095
> URL: https://issues.apache.org/jira/browse/HBASE-20095
> Project: HBase
> Issue Type: Improvement
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Critical
> Fix For: 3.0.0, 2.1.0
>
> Attachments: 20095.addendum, 20095.addendum-2.txt,
> HBASE-20095.master.001.patch, HBASE-20095.master.002.patch,
> HBASE-20095.master.003.patch, HBASE-20095.master.004.patch,
> HBASE-20095.master.005.patch, HBASE-20095.master.006.patch,
> HBASE-20095.master.007.patch, HBASE-20095.master.008.patch,
> HBASE-20095.master.009.patch, HBASE-20095.master.010.patch,
> HBASE-20095.master.011.patch, HBASE-20095.master.012.patch,
> HBASE-20095.master.013.patch, HBASE-20095.master.014.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20285) Delete all last pushed sequence ids when removing a peer or removing the serial flag for a peer
[
https://issues.apache.org/jira/browse/HBASE-20285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415522#comment-16415522
]
Hudson commented on HBASE-20285:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Delete all last pushed sequence ids when removing a peer or removing the
> serial flag for a peer
> ---
>
> Key: HBASE-20285
> URL: https://issues.apache.org/jira/browse/HBASE-20285
> Project: HBase
> Issue Type: Sub-task
> Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20285-v1.patch, HBASE-20285-v2.patch,
> HBASE-20285.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20223) Use hbase-thirdparty 2.1.0
[
https://issues.apache.org/jira/browse/HBASE-20223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415521#comment-16415521
]
Hudson commented on HBASE-20223:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Use hbase-thirdparty 2.1.0
> --
>
> Key: HBASE-20223
> URL: https://issues.apache.org/jira/browse/HBASE-20223
> Project: HBase
> Issue Type: Task
> Components: dependencies
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20223.001.patch, HBASE-20223.002.branch-2.0.patch,
> HBASE-20223.002.master.patch
>
>
> Update hbase to account for the changes to hbase-thirdparty:
> * new (internal) protobuf version
> * shaded commons-cli
> * shaded commons-collections4
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20138) Find a way to deal with the conflicts when updating replication position
[
https://issues.apache.org/jira/browse/HBASE-20138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415511#comment-16415511
]
Hudson commented on HBASE-20138:
Results for branch master
[build #274 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/274/]: (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/274//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/274//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/274//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Find a way to deal with the conflicts when updating replication position
>
>
> Key: HBASE-20138
> URL: https://issues.apache.org/jira/browse/HBASE-20138
> Project: HBase
> Issue Type: Sub-task
> Components: Replication
>Reporter: Duo Zhang
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.1.0
>
> Attachments: HBASE-20138.v1.patch, HBASE-20138.v2.patch,
> HBASE-20138.v3.patch, HBASE-20138.v4.patch, HBASE-20138.v5.patch,
> HBASE-20138.v6.patch, HBASE-20138.v7.patch
>
>
> For now if a table is not created with SERIAL_REPLICATION_SCOPE and later
> converted to SERIAL_REPLICATION_SCOPE , then we may have multiple replication
> sources which replicate the different ranges for the same region and update
> the queue storage concurrently. This will cause problem if the lower range
> finish at last since the replication position will be wrong...
> Need to find a way to deal with this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20191) Cleanup replication barrier and last pushed sequence id when deleting table
[ https://issues.apache.org/jira/browse/HBASE-20191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20191: -- Resolution: Invalid Status: Resolved (was: Patch Available) The idea does not work. > Cleanup replication barrier and last pushed sequence id when deleting table > --- > > Key: HBASE-20191 > URL: https://issues.apache.org/jira/browse/HBASE-20191 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20191.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20257) hbase-spark should not depend on com.google.code.findbugs.jsr305
[
https://issues.apache.org/jira/browse/HBASE-20257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415577#comment-16415577
]
Artem Ervits commented on HBASE-20257:
--
[~busbey] that's correct though I ran mvn clean test on that instead in the
hbase-spark directory. Your approach is much more convenient. I verified with
{code:java}
mvn verify -Dhadoop.profile=3.0 -Dhadoop-three.version=3.0.0 -pl
hbase-spark{code}
all pass
> hbase-spark should not depend on com.google.code.findbugs.jsr305
>
>
> Key: HBASE-20257
> URL: https://issues.apache.org/jira/browse/HBASE-20257
> Project: HBase
> Issue Type: Task
> Components: build
>Affects Versions: 3.0.0
>Reporter: Ted Yu
>Assignee: Artem Ervits
>Priority: Minor
> Labels: beginner
> Attachments: HBASE-20257.v01.patch, HBASE-20257.v02.patch,
> HBASE-20257.v03.patch, HBASE-20257.v04.patch
>
>
> The following can be observed in the build output of master branch:
> {code}
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed
> with message:
> We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
> Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> {code}
> Here is related snippet from hbase-spark/pom.xml:
> {code}
>
> com.google.code.findbugs
> jsr305
> {code}
> Dependency on jsr305 should be dropped.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota updated HBASE-20253:
---
Status: Open (was: Patch Available)
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota updated HBASE-20253:
---
Attachment: HBASE-20253.master.002.patch
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota updated HBASE-20253:
---
Status: Patch Available (was: Open)
fixed rubocop issue
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following command will restore all acl from snapshot table into the table.
> hbase> restore_snapshot 'snapshotName', \{RESTORE_ACL=>true}
> Took 0.1044 seconds
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20130) Use defaults (16020 & 16030) as base ports when the RS is bound to localhost
[ https://issues.apache.org/jira/browse/HBASE-20130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415617#comment-16415617 ] Chia-Ping Tsai commented on HBASE-20130: I had left some trivial comments in RB. Please take a look. Thanks. > Use defaults (16020 & 16030) as base ports when the RS is bound to localhost > > > Key: HBASE-20130 > URL: https://issues.apache.org/jira/browse/HBASE-20130 > Project: HBase > Issue Type: Bug > Components: documentation >Reporter: Chia-Ping Tsai >Assignee: Umesh Agashe >Priority: Critical > Fix For: 2.0.0 > > Attachments: hbase-20130.master.001.patch, > hbase-20130.master.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20258) Shell hangs when scanning a disabled table
[
https://issues.apache.org/jira/browse/HBASE-20258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-20258:
Attachment: HBASE-20258.master.001.patch
> Shell hangs when scanning a disabled table
> --
>
> Key: HBASE-20258
> URL: https://issues.apache.org/jira/browse/HBASE-20258
> Project: HBase
> Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Priority: Major
> Attachments: HBASE-20258.master.001.patch
>
>
> I executed the following commands against a 2.0 server:
> {code}
> disable 't'
> scan 't'
> {code}
> From client-1.2: it throws an error because the table is disabled -> OK.
> From client-2.0: the shell hangs -> NOT OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20258) Shell hangs when scanning a disabled table
[
https://issues.apache.org/jira/browse/HBASE-20258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-20258:
Assignee: Balazs Meszaros
Fix Version/s: 2.0.0
3.0.0
Status: Patch Available (was: Open)
> Shell hangs when scanning a disabled table
> --
>
> Key: HBASE-20258
> URL: https://issues.apache.org/jira/browse/HBASE-20258
> Project: HBase
> Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.0.0
>
> Attachments: HBASE-20258.master.001.patch
>
>
> I executed the following commands against a 2.0 server:
> {code}
> disable 't'
> scan 't'
> {code}
> From client-1.2: it throws an error because the table is disabled -> OK.
> From client-2.0: the shell hangs -> NOT OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20253) Error message is missing for restore_snapshot
[
https://issues.apache.org/jira/browse/HBASE-20253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415621#comment-16415621
]
Hadoop QA commented on HBASE-20253:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
33s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @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
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
38s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
7s{color} | {color:red} The patch generated 1 new + 386 unchanged - 1 fixed =
387 total (was 387) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
2s{color} | {color:red} The patch generated 3 new + 723 unchanged - 0 fixed =
726 total (was 723) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
31s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 18m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20253 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916395/HBASE-20253.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 1c6c5e145f01 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 / 2a2258656b |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| rubocop | v0.54.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/12169/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/12169/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12169/testReport/ |
| Max. process+thread count | 2122 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12169/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Error message is missing for restore_snapshot
> -
>
> Key: HBASE-20253
> URL: https://issues.apache.org/jira/browse/HBASE-20253
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Minor
> Attachments: HBASE-20253.master.001.patch,
> HBASE-20253.master.002.patch
>
>
> When the table is not disabled and restore_snapshot executed the error
> message is useless, only displays the table name.
> hbase(main):007:0> restore_snapshot 'tsnap'
> ERROR: t
> Restore a specified snapshot.
> The restore will replace the content of the original table,
> bringing back the content to the snapshot state.
> The table must be disabled.
> Examples:
> hbase> restore_snapshot 'snapshotName'
> Following comman
[jira] [Commented] (HBASE-20258) Shell hangs when scanning a disabled table
[
https://issues.apache.org/jira/browse/HBASE-20258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415623#comment-16415623
]
Hadoop QA commented on HBASE-20258:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
33s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-20258 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20258 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916396/HBASE-20258.master.001.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12170/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Shell hangs when scanning a disabled table
> --
>
> Key: HBASE-20258
> URL: https://issues.apache.org/jira/browse/HBASE-20258
> Project: HBase
> Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.0.0
>
> Attachments: HBASE-20258.master.001.patch
>
>
> I executed the following commands against a 2.0 server:
> {code}
> disable 't'
> scan 't'
> {code}
> From client-1.2: it throws an error because the table is disabled -> OK.
> From client-2.0: the shell hangs -> NOT OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20128) Add new UTs which extends the old replication UTs but set replication scope to SERIAL
[ https://issues.apache.org/jira/browse/HBASE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20128: - Attachment: HBASE-20128.v1.patch > Add new UTs which extends the old replication UTs but set replication scope > to SERIAL > - > > Key: HBASE-20128 > URL: https://issues.apache.org/jira/browse/HBASE-20128 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20128.v1.patch > > > Make sure that the basic function for replicationstill works. The serial > replication UTs are focused on order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20128) Add new UTs which extends the old replication UTs but set replication scope to SERIAL
[ https://issues.apache.org/jira/browse/HBASE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415634#comment-16415634 ] Zheng Hu commented on HBASE-20128: -- Upload patch.v1 to see if all UT work fine. > Add new UTs which extends the old replication UTs but set replication scope > to SERIAL > - > > Key: HBASE-20128 > URL: https://issues.apache.org/jira/browse/HBASE-20128 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20128.v1.patch > > > Make sure that the basic function for replicationstill works. The serial > replication UTs are focused on order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20128) Add new UTs which extends the old replication UTs but set replication scope to SERIAL
[ https://issues.apache.org/jira/browse/HBASE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-20128: - Status: Patch Available (was: Open) > Add new UTs which extends the old replication UTs but set replication scope > to SERIAL > - > > Key: HBASE-20128 > URL: https://issues.apache.org/jira/browse/HBASE-20128 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-20128.v1.patch > > > Make sure that the basic function for replicationstill works. The serial > replication UTs are focused on order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20295) TableOutputFormat.checkOutputSpecs throw NullPointerException Exception
[
https://issues.apache.org/jira/browse/HBASE-20295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jin updated HBASE-20295:
Remaining Estimate: 168h (was: 24h)
Original Estimate: 168h (was: 24h)
> TableOutputFormat.checkOutputSpecs throw NullPointerException Exception
> ---
>
> Key: HBASE-20295
> URL: https://issues.apache.org/jira/browse/HBASE-20295
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 1.4.0
> Environment: Spark 2.2.1, HBase 1.4.0
>Reporter: Michael Jin
>Priority: Major
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> I am using spark write data to HBase by using RDD.
> saveAsNewAPIHadoopDataset function, it works fine with hbase 1.3.1, but when
> update my hbase dependency to 1.4.0 in pom.xml, it throw
> java.lang.NullPointerException, it is caused by a logic error in
> TableOutputFormat.checkOutputSpecs function, please check below details:
> first let's take a look at SparkHadoopMapReduceWriter.write function in
> SparkHadoopMapReduceWriter.scala
> {code:java}
> // SparkHadoopMapReduceWriter.write
> (org.apache.spark.internal.io.SparkHadoopMapReduceWriter.scala)
> def write[K, V: ClassTag](
> rdd: RDD[(K, V)],
> hadoopConf: Configuration): Unit = {
> // Extract context and configuration from RDD.
> val sparkContext = rdd.context
> val stageId = rdd.id
> val sparkConf = rdd.conf
> val conf = new SerializableConfiguration(hadoopConf)
> // Set up a job.
> val jobTrackerId = SparkHadoopWriterUtils.createJobTrackerID(new Date())
> val jobAttemptId = new TaskAttemptID(jobTrackerId, stageId, TaskType.MAP,
> 0, 0)
> val jobContext = new TaskAttemptContextImpl(conf.value, jobAttemptId)
> val format = jobContext.getOutputFormatClass
> if (SparkHadoopWriterUtils.isOutputSpecValidationEnabled(sparkConf)) {
> // FileOutputFormat ignores the filesystem parameter
> val jobFormat = format.newInstance
> jobFormat.checkOutputSpecs(jobContext)
> }
> val committer = FileCommitProtocol.instantiate(
> className = classOf[HadoopMapReduceCommitProtocol].getName,
> jobId = stageId.toString,
> outputPath =
> conf.value.get("mapreduce.output.fileoutputformat.outputdir"),
> isAppend = false).asInstanceOf[HadoopMapReduceCommitProtocol]
> committer.setupJob(jobContext)
> ...{code}
> in "write" function if output spec validation is enabled, it will call
> checkOutputSpec function in TableOutputFormat class, but the job format is
> simply created by "vall jobFormat = format.newInstance", this will NOT
> initialize "conf" member variable in TableOutputFormat class, let's continue
> check checkOutputSpecs function in TableOutputFormat class
>
> {code:java}
> // TableOutputFormat.checkOutputSpecs
> (org.apache.hadoop.hbase.mapreduce.TableOutputFormat.java) HBASE 1.4.0
> @Override
> public void checkOutputSpecs(JobContext context) throws IOException,
> InterruptedException {
> try (Admin admin =
> ConnectionFactory.createConnection(getConf()).getAdmin()) {
> TableName tableName = TableName.valueOf(this.conf.get(OUTPUT_TABLE));
> if (!admin.tableExists(tableName)) {
> throw new TableNotFoundException("Can't write, table does not exist:" +
> tableName.getNameAsString());
> }
> if (!admin.isTableEnabled(tableName)) {
> throw new TableNotEnabledException("Can't write, table is not enabled:
> " +
> tableName.getNameAsString());
> }
> }
> }
> {code}
>
> "ConnectionFactory.createConnection(getConf())", as mentioned above "conf"
> class member is not initialized, so getConf() will return null, so in the
> next UserProvider create instance process, it throw the
> NullPointException(Please part of stack trace at the end), it is a little
> confused that, context passed by function parameter is actually been properly
> constructed, and it contains Configuration object, why context is never used?
> So I suggest to use below code to partly fix this issue:
>
> {code:java}
> // code placeholder
> @Override
> public void checkOutputSpecs(JobContext context) throws IOException,
> InterruptedException {
> Configuration hConf = context.getConfiguration();
> if(hConf == null)
> hConf = this.conf;
> try (Admin admin = ConnectionFactory.createConnection(hConf).getAdmin()) {
> TableName tableName = TableName.valueOf(hConf.get(OUTPUT_TABLE));
> if (!admin.tableExists(tableName)) {
> throw new TableNotFoundException("Can't write, table does not exist:" +
> tableName.getNameAsString());
> }
> if (!admin.isTableEnabled(tableName)) {
> throw new TableNotEnabledException("Can't write, table is not enabled:
> " +
> tableName.getNameAsString());
> }
> }
[jira] [Commented] (HBASE-20111) Able to split region explicitly even on shouldSplit return false from split policy
[
https://issues.apache.org/jira/browse/HBASE-20111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415682#comment-16415682
]
Hadoop QA commented on HBASE-20111:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{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
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
15s{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
43s{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
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
2s{color} | {color:red} hbase-server: The patch generated 9 new + 110 unchanged
- 0 fixed = 119 total (was 110) {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
21s{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 18s{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
52s{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:green}+1{color} | {color:green} unit {color} | {color:green}161m
35s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}202m 18s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20111 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916377/HBASE-20111_v3.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 60a830e4f80c 4.4.0-89-generic #112-Ubuntu SMP Mon Jul 31
19:38:41 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 / 2a2258656b |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12168/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12168/testReport/ |
| Max. process+thread count | 4572 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
http
[jira] [Updated] (HBASE-20199) Add test to prevent further permission regression around table flush and snapshot
[
https://issues.apache.org/jira/browse/HBASE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-20199:
---
Attachment: HBASE-20199.003.branch-2.0.patch
> Add test to prevent further permission regression around table flush and
> snapshot
> -
>
> Key: HBASE-20199
> URL: https://issues.apache.org/jira/browse/HBASE-20199
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20199.001.branch-2.0.patch,
> HBASE-20199.002.branch-2.0.patch, HBASE-20199.003.branch-2.0.patch
>
>
> {quote}
> There is already a test for that in TestAccessController-
> [https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java#L809],
> - however, those tests are hacked to not run the operations but the AC hooks
> directly. for eg. instead of triggering flush, it just runs
> ACCESS_CONTROLLER.preTableFlush(). It's not possible/good to change just a
> few tests there given that will break the overall design and make things
> harder to maintain.
> The new test should go in TestAdminOnlyOperations (and the test class name
> should probably be changed to TestRpcAccessChecks).
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20199) Add test to prevent further permission regression around table flush and snapshot
[
https://issues.apache.org/jira/browse/HBASE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415719#comment-16415719
]
Josh Elser commented on HBASE-20199:
Thanks, Ted. Too many things at once.
> Add test to prevent further permission regression around table flush and
> snapshot
> -
>
> Key: HBASE-20199
> URL: https://issues.apache.org/jira/browse/HBASE-20199
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20199.001.branch-2.0.patch,
> HBASE-20199.002.branch-2.0.patch, HBASE-20199.003.branch-2.0.patch
>
>
> {quote}
> There is already a test for that in TestAccessController-
> [https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java#L809],
> - however, those tests are hacked to not run the operations but the AC hooks
> directly. for eg. instead of triggering flush, it just runs
> ACCESS_CONTROLLER.preTableFlush(). It's not possible/good to change just a
> few tests there given that will break the overall design and make things
> harder to maintain.
> The new test should go in TestAdminOnlyOperations (and the test class name
> should probably be changed to TestRpcAccessChecks).
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20159) Support using separate ZK quorums for client
[
https://issues.apache.org/jira/browse/HBASE-20159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415720#comment-16415720
]
Yu Li commented on HBASE-20159:
---
We use {{hbase.client.zookeeper.quorum}} to identify the ZK nodes client should
connect, and if it's not set we will fallback to use {{hbase.zookeeper.quorum}}
just like before. The setting of {{hbase.client.zookeeper.observer.mode}} only
takes effect when {{hbase.client.zookeeper.quorum}} is set.
Back to your question, the former setting is correct when client ZK nodes in
observer mode, while the latter one is a mis-configuration
FWIW, here is a
[link|http://zookeeper.apache.org/doc/r3.4.6/zookeeperObservers.html] for more
details about zookeeper observer mode.
> Support using separate ZK quorums for client
>
>
> Key: HBASE-20159
> URL: https://issues.apache.org/jira/browse/HBASE-20159
> Project: HBase
> Issue Type: New Feature
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Major
> Attachments: HBASE-20159.patch, HBASE-20159.v2.patch,
> HBASE-20159.v3.patch
>
>
> Currently we are using the same zookeeper quorums for client and server,
> which makes us under risk that if some client connection boost exhausted
> zookeeper, RegionServer might abort due to zookeeper session loss. Actually
> we have suffered from this many times in production.
> Here we propose to allow client to use different ZK quorums, through below
> settings:
> {noformat}
> hbase.client.zookeeper.quorum
> hbase.client.zookeeper.property.clientPort
> hbase.client.zookeeper.observer.mode
> {noformat}
> The first two are for specifying client zookeeper properties, and the third
> one indicating whether the client ZK nodes are in observer mode. If the
> client ZK are not observer nodes, HMaster will take responsibility to
> synchronize necessary meta information (such as meta location and master
> address, etc.) from server to client ZK
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20258) Shell hangs when scanning a disabled table
[
https://issues.apache.org/jira/browse/HBASE-20258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-20258:
Attachment: HBASE-20258.branch-2.001.patch
> Shell hangs when scanning a disabled table
> --
>
> Key: HBASE-20258
> URL: https://issues.apache.org/jira/browse/HBASE-20258
> Project: HBase
> Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.0.0
>
> Attachments: HBASE-20258.branch-2.001.patch,
> HBASE-20258.master.001.patch
>
>
> I executed the following commands against a 2.0 server:
> {code}
> disable 't'
> scan 't'
> {code}
> From client-1.2: it throws an error because the table is disabled -> OK.
> From client-2.0: the shell hangs -> NOT OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20258) Shell hangs when scanning a disabled table
[
https://issues.apache.org/jira/browse/HBASE-20258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-20258:
Attachment: (was: HBASE-20258.master.001.patch)
> Shell hangs when scanning a disabled table
> --
>
> Key: HBASE-20258
> URL: https://issues.apache.org/jira/browse/HBASE-20258
> Project: HBase
> Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.0.0
>
> Attachments: HBASE-20258.branch-2.001.patch,
> HBASE-20258.master.001.patch
>
>
> I executed the following commands against a 2.0 server:
> {code}
> disable 't'
> scan 't'
> {code}
> From client-1.2: it throws an error because the table is disabled -> OK.
> From client-2.0: the shell hangs -> NOT OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20258) Shell hangs when scanning a disabled table
[
https://issues.apache.org/jira/browse/HBASE-20258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balazs Meszaros updated HBASE-20258:
Attachment: HBASE-20258.master.001.patch
> Shell hangs when scanning a disabled table
> --
>
> Key: HBASE-20258
> URL: https://issues.apache.org/jira/browse/HBASE-20258
> Project: HBase
> Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.0.0
>
> Attachments: HBASE-20258.branch-2.001.patch,
> HBASE-20258.master.001.patch
>
>
> I executed the following commands against a 2.0 server:
> {code}
> disable 't'
> scan 't'
> {code}
> From client-1.2: it throws an error because the table is disabled -> OK.
> From client-2.0: the shell hangs -> NOT OK.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20295) TableOutputFormat.checkOutputSpecs throw NullPointerException Exception
[
https://issues.apache.org/jira/browse/HBASE-20295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415759#comment-16415759
]
Ted Yu commented on HBASE-20295:
Have you verified that the Spark job can continue with the proposed fix ?
thanks
> TableOutputFormat.checkOutputSpecs throw NullPointerException Exception
> ---
>
> Key: HBASE-20295
> URL: https://issues.apache.org/jira/browse/HBASE-20295
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 1.4.0
> Environment: Spark 2.2.1, HBase 1.4.0
>Reporter: Michael Jin
>Priority: Major
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> I am using spark write data to HBase by using RDD.
> saveAsNewAPIHadoopDataset function, it works fine with hbase 1.3.1, but when
> update my hbase dependency to 1.4.0 in pom.xml, it throw
> java.lang.NullPointerException, it is caused by a logic error in
> TableOutputFormat.checkOutputSpecs function, please check below details:
> first let's take a look at SparkHadoopMapReduceWriter.write function in
> SparkHadoopMapReduceWriter.scala
> {code:java}
> // SparkHadoopMapReduceWriter.write
> (org.apache.spark.internal.io.SparkHadoopMapReduceWriter.scala)
> def write[K, V: ClassTag](
> rdd: RDD[(K, V)],
> hadoopConf: Configuration): Unit = {
> // Extract context and configuration from RDD.
> val sparkContext = rdd.context
> val stageId = rdd.id
> val sparkConf = rdd.conf
> val conf = new SerializableConfiguration(hadoopConf)
> // Set up a job.
> val jobTrackerId = SparkHadoopWriterUtils.createJobTrackerID(new Date())
> val jobAttemptId = new TaskAttemptID(jobTrackerId, stageId, TaskType.MAP,
> 0, 0)
> val jobContext = new TaskAttemptContextImpl(conf.value, jobAttemptId)
> val format = jobContext.getOutputFormatClass
> if (SparkHadoopWriterUtils.isOutputSpecValidationEnabled(sparkConf)) {
> // FileOutputFormat ignores the filesystem parameter
> val jobFormat = format.newInstance
> jobFormat.checkOutputSpecs(jobContext)
> }
> val committer = FileCommitProtocol.instantiate(
> className = classOf[HadoopMapReduceCommitProtocol].getName,
> jobId = stageId.toString,
> outputPath =
> conf.value.get("mapreduce.output.fileoutputformat.outputdir"),
> isAppend = false).asInstanceOf[HadoopMapReduceCommitProtocol]
> committer.setupJob(jobContext)
> ...{code}
> in "write" function if output spec validation is enabled, it will call
> checkOutputSpec function in TableOutputFormat class, but the job format is
> simply created by "vall jobFormat = format.newInstance", this will NOT
> initialize "conf" member variable in TableOutputFormat class, let's continue
> check checkOutputSpecs function in TableOutputFormat class
>
> {code:java}
> // TableOutputFormat.checkOutputSpecs
> (org.apache.hadoop.hbase.mapreduce.TableOutputFormat.java) HBASE 1.4.0
> @Override
> public void checkOutputSpecs(JobContext context) throws IOException,
> InterruptedException {
> try (Admin admin =
> ConnectionFactory.createConnection(getConf()).getAdmin()) {
> TableName tableName = TableName.valueOf(this.conf.get(OUTPUT_TABLE));
> if (!admin.tableExists(tableName)) {
> throw new TableNotFoundException("Can't write, table does not exist:" +
> tableName.getNameAsString());
> }
> if (!admin.isTableEnabled(tableName)) {
> throw new TableNotEnabledException("Can't write, table is not enabled:
> " +
> tableName.getNameAsString());
> }
> }
> }
> {code}
>
> "ConnectionFactory.createConnection(getConf())", as mentioned above "conf"
> class member is not initialized, so getConf() will return null, so in the
> next UserProvider create instance process, it throw the
> NullPointException(Please part of stack trace at the end), it is a little
> confused that, context passed by function parameter is actually been properly
> constructed, and it contains Configuration object, why context is never used?
> So I suggest to use below code to partly fix this issue:
>
> {code:java}
> // code placeholder
> @Override
> public void checkOutputSpecs(JobContext context) throws IOException,
> InterruptedException {
> Configuration hConf = context.getConfiguration();
> if(hConf == null)
> hConf = this.conf;
> try (Admin admin = ConnectionFactory.createConnection(hConf).getAdmin()) {
> TableName tableName = TableName.valueOf(hConf.get(OUTPUT_TABLE));
> if (!admin.tableExists(tableName)) {
> throw new TableNotFoundException("Can't write, table does not exist:" +
> tableName.getNameAsString());
> }
> if (!admin.isTableEnabled(tableName)) {
> throw new TableNotEnabledException("Can't write, table is not enabled:
> " +
>
[jira] [Commented] (HBASE-20287) After cluster startup list_regions command fails on disabled table
[
https://issues.apache.org/jira/browse/HBASE-20287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415766#comment-16415766
]
Peter Somogyi commented on HBASE-20287:
---
After startup hbase:meta contains the old server name for disabled tables. When
list_regions is called it fetches region load information for the old region
server which fails.
{code:java}
region_load_map = cluster_status.getLoad(server_name).getRegionsLoad{code}
> After cluster startup list_regions command fails on disabled table
> --
>
> Key: HBASE-20287
> URL: https://issues.apache.org/jira/browse/HBASE-20287
> Project: HBase
> Issue Type: Sub-task
> Components: shell
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Priority: Minor
>
> After cluster startup list_regions throw “ERROR: undefined method `toString'
> for nil:NilClass”. If you enable the table and disable it you don't see the
> error again, only after cluster startup.
> {noformat}
> After startup list_regions throw “ERROR: undefined method `toString' for
> nil:NilClass”.
> hbase(main):009:0> list_regions 'ltt'
> ERROR: undefined method `toString' for nil:NilClass
> List all regions for a particular table as an array and also filter
> them by server name (optional) as prefix
> and maximum locality (optional). By default, it will return all the
> regions for the table with any locality.
> The command displays server name, region name, start key, end key,
> size of the region in MB, number of requests
> and the locality. The information can be projected out via an array as
> third parameter. By default all these information
> is displayed. Possible array values are SERVER_NAME, REGION_NAME,
> START_KEY, END_KEY, SIZE, REQ and LOCALITY. Values
> are not case sensitive. If you don't want to filter by server name,
> pass an empty hash / string as shown below.
> Examples:
> hbase> list_regions 'table_name'
> hbase> list_regions 'table_name', 'server_name'
> hbase> list_regions 'table_name', {SERVER_NAME => 'server_name',
> LOCALITY_THRESHOLD => 0.8}
> hbase> list_regions 'table_name', {SERVER_NAME => 'server_name',
> LOCALITY_THRESHOLD => 0.8}, ['SERVER_NAME']
> hbase> list_regions 'table_name', {}, ['SERVER_NAME', 'start_key']
> hbase> list_regions 'table_name', '', ['SERVER_NAME', 'start_key']
> Took 0.0283 seconds{noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-20095) Redesign single instance pool in CleanerChore
[ https://issues.apache.org/jira/browse/HBASE-20095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415192#comment-16415192 ] Ted Yu edited comment on HBASE-20095 at 3/27/18 3:02 PM: - The test failure was for load balancer which was not related to addendum. I ran TestStochasticLoadBalancerRegionReplicaHighReplication with addendum which passed. [~mdrob]: Can you take a look at the addendum too ? was (Author: yuzhih...@gmail.com): The test failure was for load balancer which was not related to addendum. [~mdrob]: Can you take a look at the addendum too ? > Redesign single instance pool in CleanerChore > - > > Key: HBASE-20095 > URL: https://issues.apache.org/jira/browse/HBASE-20095 > Project: HBase > Issue Type: Improvement >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Critical > Fix For: 3.0.0, 2.1.0 > > Attachments: 20095.addendum, 20095.addendum-2.txt, > HBASE-20095.master.001.patch, HBASE-20095.master.002.patch, > HBASE-20095.master.003.patch, HBASE-20095.master.004.patch, > HBASE-20095.master.005.patch, HBASE-20095.master.006.patch, > HBASE-20095.master.007.patch, HBASE-20095.master.008.patch, > HBASE-20095.master.009.patch, HBASE-20095.master.010.patch, > HBASE-20095.master.011.patch, HBASE-20095.master.012.patch, > HBASE-20095.master.013.patch, HBASE-20095.master.014.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20291) Fix for The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no dependency information available with hadoop.profile=3.0
[
https://issues.apache.org/jira/browse/HBASE-20291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-20291:
---
Fix Version/s: 3.0.0
lgtm
> Fix for The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no
> dependency information available with hadoop.profile=3.0
> ---
>
> Key: HBASE-20291
> URL: https://issues.apache.org/jira/browse/HBASE-20291
> Project: HBase
> Issue Type: Bug
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20291.v01.patch
>
>
> receiving message
> {code:java}
> The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no dependency
> information available{code}
> when running with
> {code:java}
> mvn clean install -DHBasePatchProcess -Dhadoop-three.version=3.0.0
> -Dhadoop.profile=3.0 -DskipTests{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20258) Shell hangs when scanning a disabled table
[
https://issues.apache.org/jira/browse/HBASE-20258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415800#comment-16415800
]
Hadoop QA commented on HBASE-20258:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 2m
24s{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} 8m
3s{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} 4m
40s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
3s{color} | {color:red} The patch generated 4 new + 25 unchanged - 4 fixed = 29
total (was 29) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
2s{color} | {color:red} The patch generated 1 new + 14 unchanged - 0 fixed = 15
total (was 14) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 15m 47s{color}
| {color:red} hbase-shell in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 31m 56s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestReplicationShell |
| | hadoop.hbase.client.TestAdminShell |
| | hadoop.hbase.client.TestShell |
| | hadoop.hbase.client.TestQuotasShell |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20258 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916404/HBASE-20258.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit rubocop ruby_lint |
| uname | Linux 58080b1464a5 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 / 2a2258656b |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| rubocop | v0.54.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/12173/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/12173/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/12173/artifact/patchprocess/patch-unit-hbase-shell.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12173/testReport/ |
| Max. process+thread count | 2156 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/12173/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Shell hangs when scanning a disabled table
> --
>
> Key: HBASE-20258
> URL: https://issues.apache.org/jira/browse/HBASE-20258
> Project: HBase
> Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 3.0.0, 2.0.0
>
> Attachments: HBASE-20258.branch-2.001.patch,
> HBASE-20258.master.001.patch
>
>
> I executed the following commands against a 2.0 server:
> {code}
> disable 't'
> scan 't'
> {code}
> From client-1.2: it
[jira] [Commented] (HBASE-20111) Able to split region explicitly even on shouldSplit return false from split policy
[
https://issues.apache.org/jira/browse/HBASE-20111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415810#comment-16415810
]
Josh Elser commented on HBASE-20111:
I'm +1 on this change (can fix checkstyle on commit). I was able to split
{{hbase:namespace}} locally and the table doesn't have any coprocessors
attached to it which may cause other problems.
Will wait for [~stack] 's sign-off to land it into branch-2.0 though.
> Able to split region explicitly even on shouldSplit return false from split
> policy
> --
>
> Key: HBASE-20111
> URL: https://issues.apache.org/jira/browse/HBASE-20111
> Project: HBase
> Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20111.001.branch-2.0.patch, HBASE-20111.patch,
> HBASE-20111_test.patch, HBASE-20111_v2.patch, HBASE-20111_v3.patch
>
>
> Currently able to split the region explicitly even when the split policy
> returns from shouldSplit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20291) Fix for The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no dependency information available with hadoop.profile=3.0
[
https://issues.apache.org/jira/browse/HBASE-20291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-20291:
---
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Thanks for the patch, Artem
> Fix for The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no
> dependency information available with hadoop.profile=3.0
> ---
>
> Key: HBASE-20291
> URL: https://issues.apache.org/jira/browse/HBASE-20291
> Project: HBase
> Issue Type: Bug
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20291.v01.patch
>
>
> receiving message
> {code:java}
> The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no dependency
> information available{code}
> when running with
> {code:java}
> mvn clean install -DHBasePatchProcess -Dhadoop-three.version=3.0.0
> -Dhadoop.profile=3.0 -DskipTests{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415843#comment-16415843
]
Hudson commented on HBASE-20292:
Results for branch branch-2
[build #536 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/536/]:
(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/branch-2/536//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/536//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/536//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20111) Able to split region explicitly even on shouldSplit return false from split policy
[
https://issues.apache.org/jira/browse/HBASE-20111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415844#comment-16415844
]
Ted Yu commented on HBASE-20111:
{code}
+// Even after setting force split if split policy says no to split
then we should not split.
+shouldSplit = region.getSplitPolicy().shouldSplit() &&
!(info.isMetaRegion());
bestSplitRow = r.checkSplit();
{code}
{{checkSplit}} already has check w.r.t. system tables:
{code}
if (this.getRegionInfo().isMetaRegion() ||
TableName.NAMESPACE_TABLE_NAME.equals(this.getRegionInfo().getTable()))
{
{code}
It seems {{shouldSplit}} should take into account the value of {{bestSplitRow}}
- if {{bestSplitRow}} is null, {{shouldSplit}} should be false.
> Able to split region explicitly even on shouldSplit return false from split
> policy
> --
>
> Key: HBASE-20111
> URL: https://issues.apache.org/jira/browse/HBASE-20111
> Project: HBase
> Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20111.001.branch-2.0.patch, HBASE-20111.patch,
> HBASE-20111_test.patch, HBASE-20111_v2.patch, HBASE-20111_v3.patch
>
>
> Currently able to split the region explicitly even when the split policy
> returns from shouldSplit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-15686) Add override mechanism for the exempt classes when dynamically loading table coprocessor
[
https://issues.apache.org/jira/browse/HBASE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415855#comment-16415855
]
kanwaljeet sachdev commented on HBASE-15686:
I am hitting the class loader exception shared in the post above with the
following setup config
# Hbase 2.0 beta1 and beta2
# HDFS 3.0 alpha 4
# I I pull the hadoop code from trunk branch and use
hadoop-yarn-server-timelineservice-hbase-coprocessor-3.2.0-SNAPSHOT.jar on the
machine to later create the schema for ATSV2 and get the same exception as
shared above.
Looking at this thread, I would assume the fix for class loading already exists
in Hbase2.0 and hence must be there in beta as well. Could someone share why
this is still happening?
> Add override mechanism for the exempt classes when dynamically loading table
> coprocessor
>
>
> Key: HBASE-15686
> URL: https://issues.apache.org/jira/browse/HBASE-15686
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors
>Affects Versions: 1.0.1
>Reporter: Sangjin Lee
>Assignee: Ted Yu
>Priority: Major
> Fix For: 1.4.0, 0.98.20, 2.0.0
>
> Attachments: 15686.v2.txt, 15686.v3.txt, 15686.v4.txt, 15686.v5.txt,
> 15686.v6.txt, 15686.wip
>
>
> As part of Hadoop's Timeline Service v.2 (YARN-2928), we're adding a table
> coprocessor (YARN-4062). However, we're finding that the coprocessor cannot
> be loaded dynamically. A relevant snippet for the exception:
> {noformat}
> java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1329)
> at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1269)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:398)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:42436)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2031)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:324)
> at
> org.apache.hadoop.hbase.master.HMaster.checkClassLoading(HMaster.java:1483)
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1327)
> ... 8 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.loadClass(CoprocessorClassLoader.java:275)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:322)
> ... 10 more
> {noformat}
> We tracked it down to the fact that {{CoprocessorClassLoader}} regarding all
> hadoop classes as exempt from loading from the coprocessor jar. Since our
> coprocessor sits in the coprocessor jar, and yet the loading of this class is
> delegated to the parent which does not have this jar, the classloading fails.
> What would be nice is the ability to exclude certain classes from the exempt
> classes so that they can be loaded via table coprocessor classloader. See
> hadoop's {{ApplicationClassLoader}} for a similar feature.
> Is there any other way to load this coprocessor at the table scope?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20266) Review current set of ignored tests
[
https://issues.apache.org/jira/browse/HBASE-20266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415859#comment-16415859
]
stack commented on HBASE-20266:
---
Thanks for input [~brfrn169]
> Review current set of ignored tests
> ---
>
> Key: HBASE-20266
> URL: https://issues.apache.org/jira/browse/HBASE-20266
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0
>
>
> [~Apache9] turned up a list of currently ignored tests. At first blush, its
> fine to ignore some such as TestHTraceHooks and TestRegionsOnMaster but
> others could do with a review. This issue is about looking at list to make
> sure nothing important missed for hbase2 and that we for sure marked why a
> test was ignored with comment and that there is a follow-on to enable JIRA.
> {code}
> TestRpcHandlerException
> TestRSKilledWhenInitializing
> TestHTraceHooks
> TestAsyncTableGetMultiThreadedWithEagerCompaction
> TestStochasticBalancerJmxMetrics
> TestReplicator
> TestQuotaThrottle
> TestFavoredStochasticLoadBalancer
> TestAsyncTableGetMultiThreadedWithBasicCompaction
> TestRegionPlacement
> TestMasterTransitions
> TestMemstoreLABWithoutPool
> TestRegionsOnMasterOptions
> TestRestoreSnapshotFromClientWithRegionReplicas
> TestMasterBalanceThrottling
> TestMasterProcedureWalLease
> TestRegionServerReadRequestMetrics
> TestHttpServerLifecycle
> TestHRegionServerBulkLoadWithOldSecureEndpoint
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20292) Wrong URLs in the descriptions for update_all_config and update_config commands in shell
[
https://issues.apache.org/jira/browse/HBASE-20292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415869#comment-16415869
]
Hudson commented on HBASE-20292:
Results for branch branch-2.0
[build #95 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/95/]:
(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/branch-2.0/95//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/95//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/95//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Wrong URLs in the descriptions for update_all_config and update_config
> commands in shell
>
>
> Key: HBASE-20292
> URL: https://issues.apache.org/jira/browse/HBASE-20292
> Project: HBase
> Issue Type: Bug
> Components: shell
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Trivial
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.0
>
> Attachments: HBASE-20292.master.001.patch
>
>
> When running help command for update_config and update_all_config in shell,
> the following output is shown but the URLs in the output are wrong.
> {code}
> hbase(main):002:0> help "update_config"
> Reload a subset of configuration on server 'servername' where servername is
> host, port plus startcode. For example:
> host187.example.com,60020,1289493121758
> See http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_config 'servername'
> hbase(main):003:0> help "update_all_config"
> Reload a subset of configuration on all servers in the cluster. See
> http://hbase.apache.org/book.html?dyn_config for more details. Here is how
> you would run the command in the hbase shell:
> hbase> update_all_config
> {code}
> We should change the URLs http://hbase.apache.org/book.html?dyn_config to
> http://hbase.apache.org/book.html#dyn_config (replicing '?' with '#').
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20159) Support using separate ZK quorums for client
[
https://issues.apache.org/jira/browse/HBASE-20159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415870#comment-16415870
]
Reid Chan commented on HBASE-20159:
---
Thanks Yu, it's clear.
> Support using separate ZK quorums for client
>
>
> Key: HBASE-20159
> URL: https://issues.apache.org/jira/browse/HBASE-20159
> Project: HBase
> Issue Type: New Feature
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Major
> Attachments: HBASE-20159.patch, HBASE-20159.v2.patch,
> HBASE-20159.v3.patch
>
>
> Currently we are using the same zookeeper quorums for client and server,
> which makes us under risk that if some client connection boost exhausted
> zookeeper, RegionServer might abort due to zookeeper session loss. Actually
> we have suffered from this many times in production.
> Here we propose to allow client to use different ZK quorums, through below
> settings:
> {noformat}
> hbase.client.zookeeper.quorum
> hbase.client.zookeeper.property.clientPort
> hbase.client.zookeeper.observer.mode
> {noformat}
> The first two are for specifying client zookeeper properties, and the third
> one indicating whether the client ZK nodes are in observer mode. If the
> client ZK are not observer nodes, HMaster will take responsibility to
> synchronize necessary meta information (such as meta location and master
> address, etc.) from server to client ZK
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled
[ https://issues.apache.org/jira/browse/HBASE-20280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415876#comment-16415876 ] Zach York commented on HBASE-20280: --- Yes, the fix for reopening files when a closed channel exception occurs causes this. Yes, this is normal when the thread is interrupted, but with BucketCache causes closed channel exceptions to be thrown after this. The initial fix is still valid, but needs to not include ClosedByInterruptException otherwise we will never break out of the loop. > Fix possibility of deadlocking in refreshFileConnections when prefetch is > enabled > - > > Key: HBASE-20280 > URL: https://issues.apache.org/jira/browse/HBASE-20280 > Project: HBase > Issue Type: Bug > Components: BucketCache >Affects Versions: 2.0.0-beta-2, 1.4.2 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Attachments: HBASE-20280.master.001.patch > > > When prefetch on open is specified, there is a deadlocking case > where if the prefetch is cancelled, the PrefetchExecutor interrupts > the threads if necessary, when that happens in FileIOEngine, it > causes an ClosedByInterruptException which is a subclass of > ClosedChannelException. If we retry all ClosedChannelExceptions, > this will lock as this access is expected to be interrupted. > This change removes calling refreshFileConnections for > ClosedByInterruptExceptions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20111) Able to split region explicitly even on shouldSplit return false from split policy
[
https://issues.apache.org/jira/browse/HBASE-20111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415886#comment-16415886
]
Josh Elser commented on HBASE-20111:
{quote}{{checkSplit}} already has check w.r.t. system tables:
{quote}
I think I'd disagree with you, although I see what lead you to this opinion. I
read this code as the intent of {{splittable}} is more about overt details of
this region which are not tied to the lifecycle of this region: e.g. split
policy, not a 'special' system table. {{checkSplit}} more encapsulates logic
about whether we can (right now) split the region.
{quote}It seems {{shouldSplit}} should take into account the value of
{{bestSplitRow}} - if {{bestSplitRow}} is null, {{shouldSplit}} should be false.
{quote}
This is handled in the Master which I think is the right place for it to
happen. You're right that if this RPC would return that the region is
splittable, the user did not provide a row to split upon, and the region could
not provide a row to split upon, that should be an assertion failure.
{code:java}
if (node != null) {
try {
if (bestSplitRow == null || bestSplitRow.length == 0) {
LOG.info("splitKey isn't explicitly specified, " + " will try to find
a best split key from RS");
}
// Always set bestSplitRow request as true here,
// need to call Region#checkSplit to check it splittable or not
GetRegionInfoResponse response =
Util.getRegionInfoResponse(env, node.getRegionLocation(),
node.getRegionInfo(), true);
if(bestSplitRow == null || bestSplitRow.length == 0) {
bestSplitRow = response.hasBestSplitRow() ?
response.getBestSplitRow().toByteArray() : null;
}
splittable = response.hasSplittable() && response.getSplittable();
if (LOG.isDebugEnabled()) {
LOG.debug("Splittable=" + splittable + " " + node.toShortString());
}
} catch (IOException e) {
splittableCheckIOE = e;
}
}
if (!splittable) {
IOException e = new
DoNotRetryIOException(regionToSplit.getShortNameToLog() + " NOT splittable");
if (splittableCheckIOE != null) e.initCause(splittableCheckIOE);
throw e;
}
if(bestSplitRow == null || bestSplitRow.length == 0) {
throw new DoNotRetryIOException("Region not splittable because
bestSplitPoint = null, "
+ "maybe table is too small for auto split. For force split, try
specifying split row");
}{code}
IMO, what we have already covers this pretty well since the SplitTableProcedure
could still proceed with a user-provided split key if the Region could not
compute one for some reason.
That said, the {{isClosing()}} check done in {{HRegion.checkSplit()}} does
sound like it should be lifted out of this method and set explicitly on
{{isSplittable}}..
> Able to split region explicitly even on shouldSplit return false from split
> policy
> --
>
> Key: HBASE-20111
> URL: https://issues.apache.org/jira/browse/HBASE-20111
> Project: HBase
> Issue Type: Bug
>Reporter: Rajeshbabu Chintaguntla
>Assignee: Rajeshbabu Chintaguntla
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20111.001.branch-2.0.patch, HBASE-20111.patch,
> HBASE-20111_test.patch, HBASE-20111_v2.patch, HBASE-20111_v3.patch
>
>
> Currently able to split the region explicitly even when the split policy
> returns from shouldSplit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-20290) Typo in enable_table_replication error message
[
https://issues.apache.org/jira/browse/HBASE-20290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota reassigned HBASE-20290:
--
Assignee: Gabor Bota
> Typo in enable_table_replication error message
> --
>
> Key: HBASE-20290
> URL: https://issues.apache.org/jira/browse/HBASE-20290
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.2.6
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Trivial
> Labels: beginner
>
>
> Typo: comapred
> {noformat}
> hbase(main):020:0> enable_table_replication 'repl'
> ERROR: Table repl exists in peer cluster 1, but the table descriptors are not
> same when comapred with source cluster. Thus can not enable the table's
> replication switch.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20290) Typo in enable_table_replication error message
[
https://issues.apache.org/jira/browse/HBASE-20290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota updated HBASE-20290:
---
Status: Patch Available (was: Open)
> Typo in enable_table_replication error message
> --
>
> Key: HBASE-20290
> URL: https://issues.apache.org/jira/browse/HBASE-20290
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.2.6
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Trivial
> Labels: beginner
> Attachments: HBASE-20290.branch-1.2.001.patch
>
>
>
> Typo: comapred
> {noformat}
> hbase(main):020:0> enable_table_replication 'repl'
> ERROR: Table repl exists in peer cluster 1, but the table descriptors are not
> same when comapred with source cluster. Thus can not enable the table's
> replication switch.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20290) Typo in enable_table_replication error message
[
https://issues.apache.org/jira/browse/HBASE-20290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gabor Bota updated HBASE-20290:
---
Attachment: HBASE-20290.branch-1.2.001.patch
> Typo in enable_table_replication error message
> --
>
> Key: HBASE-20290
> URL: https://issues.apache.org/jira/browse/HBASE-20290
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.2.6
>Reporter: Peter Somogyi
>Assignee: Gabor Bota
>Priority: Trivial
> Labels: beginner
> Attachments: HBASE-20290.branch-1.2.001.patch
>
>
>
> Typo: comapred
> {noformat}
> hbase(main):020:0> enable_table_replication 'repl'
> ERROR: Table repl exists in peer cluster 1, but the table descriptors are not
> same when comapred with source cluster. Thus can not enable the table's
> replication switch.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20128) Add new UTs which extends the old replication UTs but set replication scope to SERIAL
[
https://issues.apache.org/jira/browse/HBASE-20128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415905#comment-16415905
]
Hadoop QA commented on HBASE-20128:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
33s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
4s{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
52s{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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
37s{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
10s{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
45s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
19m 11s{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
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
28s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}130m 22s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}175m 31s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleAsyncWAL
|
| | hadoop.hbase.replication.TestReplicationStatus |
| | hadoop.hbase.replication.TestReplicationDisableInactivePeer |
| | hadoop.hbase.replication.TestReplicationKillRS |
| |
hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleAsyncWAL |
| |
hadoop.hbase.replication.multiwal.TestReplicationSyncUpToolWithMultipleWAL |
| | hadoop.hbase.replication.TestReplicationDroppedTables |
| | hadoop.hbase.replication.TestNamespaceReplication |
| | hadoop.hbase.replication.TestReplicationEndpoint |
| | hadoop.hbase.client.replication.TestReplicationAdminWithClusters |
| | hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleWAL |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20128 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916398/HBASE-20128.v1.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 0b88ff17f6dc 3.13.0-139-generic #188-Ubuntu SMP Tu
[jira] [Commented] (HBASE-20289) Comparator for NormalizationPlan breaks comparator's convention
[ https://issues.apache.org/jira/browse/HBASE-20289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415915#comment-16415915 ] Yuki Tawara commented on HBASE-20289: - Sorry, I'll do so from next time. Thank you for your fix, Ted. > Comparator for NormalizationPlan breaks comparator's convention > --- > > Key: HBASE-20289 > URL: https://issues.apache.org/jira/browse/HBASE-20289 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Yuki Tawara >Assignee: Yuki Tawara >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20289.master.001.patch > > > Comparator must meet the condition: sign(comparator(plan1, plan2)) = - > sign(comparator(plan2, plan1)). > Current implementation breaks above condition. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20111) Able to split region explicitly even on shouldSplit return false from split policy
[ https://issues.apache.org/jira/browse/HBASE-20111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415932#comment-16415932 ] Ted Yu commented on HBASE-20111: Sounds good to me. > Able to split region explicitly even on shouldSplit return false from split > policy > -- > > Key: HBASE-20111 > URL: https://issues.apache.org/jira/browse/HBASE-20111 > Project: HBase > Issue Type: Bug >Reporter: Rajeshbabu Chintaguntla >Assignee: Rajeshbabu Chintaguntla >Priority: Critical > Fix For: 2.0.0 > > Attachments: HBASE-20111.001.branch-2.0.patch, HBASE-20111.patch, > HBASE-20111_test.patch, HBASE-20111_v2.patch, HBASE-20111_v3.patch > > > Currently able to split the region explicitly even when the split policy > returns from shouldSplit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled
[ https://issues.apache.org/jira/browse/HBASE-20280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415937#comment-16415937 ] Anoop Sam John commented on HBASE-20280: +1 > Fix possibility of deadlocking in refreshFileConnections when prefetch is > enabled > - > > Key: HBASE-20280 > URL: https://issues.apache.org/jira/browse/HBASE-20280 > Project: HBase > Issue Type: Bug > Components: BucketCache >Affects Versions: 2.0.0-beta-2, 1.4.2 >Reporter: Zach York >Assignee: Zach York >Priority: Major > Attachments: HBASE-20280.master.001.patch > > > When prefetch on open is specified, there is a deadlocking case > where if the prefetch is cancelled, the PrefetchExecutor interrupts > the threads if necessary, when that happens in FileIOEngine, it > causes an ClosedByInterruptException which is a subclass of > ClosedChannelException. If we retry all ClosedChannelExceptions, > this will lock as this access is expected to be interrupted. > This change removes calling refreshFileConnections for > ClosedByInterruptExceptions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20290) Typo in enable_table_replication error message
[
https://issues.apache.org/jira/browse/HBASE-20290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415942#comment-16415942
]
Hadoop QA commented on HBASE-20290:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
25s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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.2 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
48s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} branch-1.2 passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} branch-1.2 passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{color} | {color:green} branch-1.2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
12s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} branch-1.2 passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
22s{color} | {color:green} branch-1.2 passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
16s{color} | {color:green} the patch passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
19s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
30s{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
44s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 52s{color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.5 2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed with JDK v1.8.0_163 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} the patch passed with JDK v1.7.0_171 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
0s{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} 22m 33s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:e77c578 |
| JIRA Issue | HBASE-20290 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916422/HBASE-20290.branch-1.2.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
|
[jira] [Updated] (HBASE-20224) Web UI is broken in standalone mode
[ https://issues.apache.org/jira/browse/HBASE-20224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20224: --- Attachment: 20224.addendum.4 > Web UI is broken in standalone mode > --- > > Key: HBASE-20224 > URL: https://issues.apache.org/jira/browse/HBASE-20224 > Project: HBase > Issue Type: Bug > Components: UI, Usability >Affects Versions: 2.0.0-beta-2 >Reporter: Umesh Agashe >Assignee: Umesh Agashe >Priority: Blocker > Fix For: 2.0.0 > > Attachments: > 0001-HBASE-20224-Web-UI-is-broken-in-standalone-mode-ADDE.ADDENDUM.patch, > 20224-addendum.3.txt, 20224.addendum.4, hbase-20224.master.001.patch, > hbase-20224.master.002.patch, hbase-20224.master.003.patch, > hbase-20224.master.addendum.patch > > > Web UI doesn't show up in standalone mode on default port. This can be seen > on master and branch-2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20224) Web UI is broken in standalone mode
[
https://issues.apache.org/jira/browse/HBASE-20224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415956#comment-16415956
]
Ted Yu commented on HBASE-20224:
There are some failing tests in the following form:
{code}
Running org.apache.hbase.archetypes.exemplars.client.TestHelloHBase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 sec <<<
FAILURE! - in org.apache.hbase.archetypes.exemplars.client.TestHelloHBase
org.apache.hbase.archetypes.exemplars.client.TestHelloHBase Time elapsed:
0.007 sec <<< ERROR!
java.io.IOException: Shutting down
at
org.apache.hbase.archetypes.exemplars.client.TestHelloHBase.beforeClass(TestHelloHBase.java:54)
Caused by: java.lang.RuntimeException: Failed construction of RegionServer:
class org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer
at
org.apache.hbase.archetypes.exemplars.client.TestHelloHBase.beforeClass(TestHelloHBase.java:54)
Caused by: java.lang.IllegalArgumentException: port out of range:-1
at
org.apache.hbase.archetypes.exemplars.client.TestHelloHBase.beforeClass(TestHelloHBase.java:54)
{code}
The above was due to hbase-site.xml missing from test resources of
hbase-archetypes/hbase-shaded-client-project and
hbase-archetypes/hbase-client-project
With addendum 4, the tests pass.
> Web UI is broken in standalone mode
> ---
>
> Key: HBASE-20224
> URL: https://issues.apache.org/jira/browse/HBASE-20224
> Project: HBase
> Issue Type: Bug
> Components: UI, Usability
>Affects Versions: 2.0.0-beta-2
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments:
> 0001-HBASE-20224-Web-UI-is-broken-in-standalone-mode-ADDE.ADDENDUM.patch,
> 20224-addendum.3.txt, 20224.addendum.4, hbase-20224.master.001.patch,
> hbase-20224.master.002.patch, hbase-20224.master.003.patch,
> hbase-20224.master.addendum.patch
>
>
> Web UI doesn't show up in standalone mode on default port. This can be seen
> on master and branch-2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20199) Add test to prevent further permission regression around table flush and snapshot
[
https://issues.apache.org/jira/browse/HBASE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415960#comment-16415960
]
Hadoop QA commented on HBASE-20199:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} branch-2.0 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
36s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
50s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
14s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
26s{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
18s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
55s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
14s{color} | {color:red} hbase-server: The patch generated 1 new + 0 unchanged
- 0 fixed = 1 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} shadedjars {color} | {color:green} 4m
57s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
18m 0s{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
30s{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}117m
34s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}163m 58s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:9f2f2db |
| JIRA Issue | HBASE-20199 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12916401/HBASE-20199.003.branch-2.0.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 153c76092de8 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@2/component/dev-support/hbase-personality.sh
|
| git revision | branch-2.0 / cbea942efb |
| maven | version: Apache Maven 3.5.3
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/12172/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/12172/testReport/ |
| Max. process+thread count | 4435 (vs. ulimit of 1) |
| modules | C: hbase-server U: h
[jira] [Commented] (HBASE-20199) Add test to prevent further permission regression around table flush and snapshot
[
https://issues.apache.org/jira/browse/HBASE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415964#comment-16415964
]
Ted Yu commented on HBASE-20199:
+1
> Add test to prevent further permission regression around table flush and
> snapshot
> -
>
> Key: HBASE-20199
> URL: https://issues.apache.org/jira/browse/HBASE-20199
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20199.001.branch-2.0.patch,
> HBASE-20199.002.branch-2.0.patch, HBASE-20199.003.branch-2.0.patch
>
>
> {quote}
> There is already a test for that in TestAccessController-
> [https://github.com/apache/hbase/blob/master/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java#L809],
> - however, those tests are hacked to not run the operations but the AC hooks
> directly. for eg. instead of triggering flush, it just runs
> ACCESS_CONTROLLER.preTableFlush(). It's not possible/good to change just a
> few tests there given that will break the overall design and make things
> harder to maintain.
> The new test should go in TestAdminOnlyOperations (and the test class name
> should probably be changed to TestRpcAccessChecks).
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-15686) Add override mechanism for the exempt classes when dynamically loading table coprocessor
[
https://issues.apache.org/jira/browse/HBASE-15686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415855#comment-16415855
]
kanwaljeet sachdev edited comment on HBASE-15686 at 3/27/18 5:29 PM:
-
I am hitting a similar(not same) class loader exception shared in the post
above with the following setup config
# Hbase 2.0 beta1 and beta2
# HDFS 3.0 alpha 4
# I I pull the hadoop code from trunk branch and use
hadoop-yarn-server-timelineservice-hbase-coprocessor-3.2.0-SNAPSHOT.jar on the
machine to later create the schema for ATSV2 and get a similar exception as
shared above.
Looking at this thread, I would assume the fix for class loading already exists
in Hbase2.0 and hence must be there in beta as well.
was (Author: kanwaljeet):
I am hitting the class loader exception shared in the post above with the
following setup config
# Hbase 2.0 beta1 and beta2
# HDFS 3.0 alpha 4
# I I pull the hadoop code from trunk branch and use
hadoop-yarn-server-timelineservice-hbase-coprocessor-3.2.0-SNAPSHOT.jar on the
machine to later create the schema for ATSV2 and get the same exception as
shared above.
Looking at this thread, I would assume the fix for class loading already exists
in Hbase2.0 and hence must be there in beta as well. Could someone share why
this is still happening?
> Add override mechanism for the exempt classes when dynamically loading table
> coprocessor
>
>
> Key: HBASE-15686
> URL: https://issues.apache.org/jira/browse/HBASE-15686
> Project: HBase
> Issue Type: Improvement
> Components: Coprocessors
>Affects Versions: 1.0.1
>Reporter: Sangjin Lee
>Assignee: Ted Yu
>Priority: Major
> Fix For: 1.4.0, 0.98.20, 2.0.0
>
> Attachments: 15686.v2.txt, 15686.v3.txt, 15686.v4.txt, 15686.v5.txt,
> 15686.v6.txt, 15686.wip
>
>
> As part of Hadoop's Timeline Service v.2 (YARN-2928), we're adding a table
> coprocessor (YARN-4062). However, we're finding that the coprocessor cannot
> be loaded dynamically. A relevant snippet for the exception:
> {noformat}
> java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1329)
> at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1269)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:398)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:42436)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2031)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Class
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> cannot be loaded
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:324)
> at
> org.apache.hadoop.hbase.master.HMaster.checkClassLoading(HMaster.java:1483)
> at
> org.apache.hadoop.hbase.master.HMaster.sanityCheckTableDescriptor(HMaster.java:1327)
> ... 8 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.hadoop.yarn.server.timelineservice.storage.flow.FlowRunCoprocessor
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.apache.hadoop.hbase.util.CoprocessorClassLoader.loadClass(CoprocessorClassLoader.java:275)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.testTableCoprocessorAttrs(RegionCoprocessorHost.java:322)
> ... 10 more
> {noformat}
> We tracked it down to the fact that {{CoprocessorClassLoader}} regarding all
> hadoop classes as exempt from loading from the coprocessor jar. Since our
> coprocessor sits in the coprocessor jar, and yet the loading of this class is
> delegated to the parent which does not have this jar, the classloading fails.
> What would be nice is the ability to exclude certain classes from the exempt
> classes so that they can be loaded via tab
[jira] [Commented] (HBASE-18309) Support multi threads in CleanerChore
[ https://issues.apache.org/jira/browse/HBASE-18309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415969#comment-16415969 ] Zach York commented on HBASE-18309: --- [~reidchan] I see that HBASE-20095 just made it in. Do you think you still have time to do a branch-1 patch? > Support multi threads in CleanerChore > - > > Key: HBASE-18309 > URL: https://issues.apache.org/jira/browse/HBASE-18309 > Project: HBase > Issue Type: Improvement >Reporter: binlijin >Assignee: Reid Chan >Priority: Major > Fix For: 2.0.0-beta-1, 2.0.0 > > Attachments: HBASE-18309.addendum.patch, > HBASE-18309.master.001.patch, HBASE-18309.master.002.patch, > HBASE-18309.master.004.patch, HBASE-18309.master.005.patch, > HBASE-18309.master.006.patch, HBASE-18309.master.007.patch, > HBASE-18309.master.008.patch, HBASE-18309.master.009.patch, > HBASE-18309.master.010.patch, HBASE-18309.master.011.patch, > HBASE-18309.master.012.patch, space_consumption_in_archive.png > > > There is only one thread in LogCleaner to clean oldWALs and in our big > cluster we find this is not enough. The number of files under oldWALs reach > the max-directory-items limit of HDFS and cause region server crash, so we > use multi threads for LogCleaner and the crash not happened any more. > What's more, currently there's only one thread iterating the archive > directory, and we could use multiple threads cleaning sub directories in > parallel to speed it up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20095) Redesign single instance pool in CleanerChore
[ https://issues.apache.org/jira/browse/HBASE-20095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16415972#comment-16415972 ] Ted Yu commented on HBASE-20095: [~mdrob]: Please take a look at the addendum. > Redesign single instance pool in CleanerChore > - > > Key: HBASE-20095 > URL: https://issues.apache.org/jira/browse/HBASE-20095 > Project: HBase > Issue Type: Improvement >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Critical > Fix For: 3.0.0, 2.1.0 > > Attachments: 20095.addendum, 20095.addendum-2.txt, > HBASE-20095.master.001.patch, HBASE-20095.master.002.patch, > HBASE-20095.master.003.patch, HBASE-20095.master.004.patch, > HBASE-20095.master.005.patch, HBASE-20095.master.006.patch, > HBASE-20095.master.007.patch, HBASE-20095.master.008.patch, > HBASE-20095.master.009.patch, HBASE-20095.master.010.patch, > HBASE-20095.master.011.patch, HBASE-20095.master.012.patch, > HBASE-20095.master.013.patch, HBASE-20095.master.014.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
