[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Attachment: hbase-21780.master.002.patch > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement > Components: UI, Usability >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png, RS_ZKQuorum_afterPatch.png, > hbase-21780.master.001.patch, hbase-21780.master.002.patch > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21782) LoadIncrementalHFiles should not be IA.Public
Duo Zhang created HBASE-21782: - Summary: LoadIncrementalHFiles should not be IA.Public Key: HBASE-21782 URL: https://issues.apache.org/jira/browse/HBASE-21782 Project: HBase Issue Type: Task Reporter: Duo Zhang It is an implementation class, so some of the methods which are only supposed to be used by replication sink are also public to users. And it exposes methods which take Table and Connection as parameter and inside the implementation we assume that they are HTable and ConnectionImplementation, which will be a pain when we want to replace the sync client implementation with async client. Here I think we should make the implementation class as IA.LimitPrivate(TOOL), and introduce an interface for bulking hfiles programmatically. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21781) list_deadservers elapsed time is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751966#comment-16751966
]
Hadoop QA commented on HBASE-21781:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-1.4 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
29s{color} | {color:green} branch-1.4 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
16s{color} | {color:green} branch-1.4 passed with JDK v1.8.0_201 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
11s{color} | {color:green} branch-1.4 passed with JDK v1.7.0_201 {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:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
7s{color} | {color:red} The patch generated 2 new + 4 unchanged - 2 fixed = 6
total (was 6) {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
2s{color} | {color:green} There were no new ruby-lint issues. {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
8s{color} | {color:green} the patch passed with JDK v1.8.0_201 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
11s{color} | {color:green} the patch passed with JDK v1.7.0_201 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
12s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 20m 3s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:2cf636a |
| JIRA Issue | HBASE-21781 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956280/HBASE-21781.branch-1.4.0001.patch
|
| Optional Tests | dupname asflicense javac javadoc unit rubocop
ruby_lint |
| uname | Linux 5ee6b395e7b3 4.4.0-138-generic #164~14.04.1-Ubuntu SMP Fri Oct
5 08:56:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-1.4 / 7d549dd |
| maven | version: Apache Maven 3.0.5 |
| Default Java | 1.7.0_201 |
| Multi-JDK versions | /usr/lib/jvm/java-8-openjdk-amd64:1.8.0_201
/usr/lib/jvm/java-7-openjdk-amd64:1.7.0_201 |
| rubocop | v0.63.1 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/15733/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/15733/testReport/ |
| Max. process+thread count | 1596 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15733/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> list_deadservers elapsed time is incorrect
> --
>
> Key: HBASE-21781
> URL: https://issues.apache.org/jira/browse/HBASE-21781
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.4.9
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21781.branch-1.4.0001.patch
>
>
> HBASE-18131 add list_deadservers and clear_deadservers shell. In branch-1.4,
> list_deadservers elapsed time is incorrect. As follows,
> {code:java}
> hbase(main):006:0> list_deads
[jira] [Commented] (HBASE-21779) Reimplement SecureBulkLoadClient to use AsyncClusterConnection
[ https://issues.apache.org/jira/browse/HBASE-21779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751967#comment-16751967 ] Duo Zhang commented on HBASE-21779: --- Oh it is a bit difficult, as LoadIncrementalHFiles is IA.Public and it exposes methods which use Table and Connection as parameters. Let me think how to deal with this. Maybe we need to introduce a new class to implement the function, and this time only mark the interface as IA.Public, and implementation can be marked as IA.LimitPrivate(TOOL). > Reimplement SecureBulkLoadClient to use AsyncClusterConnection > -- > > Key: HBASE-21779 > URL: https://issues.apache.org/jira/browse/HBASE-21779 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > > So we will not rely on the RpcRetryingCaller and ServiceCallable any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-21773) rowcounter utility should respond to pleas for help
[
https://issues.apache.org/jira/browse/HBASE-21773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-21773 started by Wellington Chevreuil.
> rowcounter utility should respond to pleas for help
> ---
>
> Key: HBASE-21773
> URL: https://issues.apache.org/jira/browse/HBASE-21773
> Project: HBase
> Issue Type: Bug
> Components: tooling
>Affects Versions: 2.1.0
>Reporter: Sean Busbey
>Assignee: Wellington Chevreuil
>Priority: Critical
>
> {{hbase rowcounter}} does not respond to reasonable requests for help, i.e.
> {{--help}}, {{-h}}, or {{-?}}
> {code}
> [systest@busbey-training-1 root]$ hbase rowcounter -?
> OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and
> will likely be removed in a future release
> 19/01/24 12:30:00 INFO client.RMProxy: Connecting to ResourceManager at
> busbey-training-1.gce.cloudera.com/172.31.116.31:8032
> 19/01/24 12:30:01 INFO hdfs.DFSClient: Created token for systest:
> HDFS_DELEGATION_TOKEN owner=syst...@gce.cloudera.com, renewer=yarn,
> realUser=, issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3,
> masterKeyId=8 on 172.31.116.31:8020
> 19/01/24 12:30:01 INFO kms.KMSClientProvider: Getting new token from
> https://busbey-training-3.gce.cloudera.com:16000/kms/v1/,
> renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
> kms-dt, Service: 172.31.116.52:16000, Ident: (kms-dt owner=systest,
> renewer=yarn, realUser=, issueDate=1548361801965, maxDate=1548966601965,
> sequenceNumber=5, masterKeyId=17))
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: HDFS_DELEGATION_TOKEN,
> Service: 172.31.116.31:8020, Ident: (token for systest: HDFS_DELEGATION_TOKEN
> owner=syst...@gce.cloudera.com, renewer=yarn, realUser=,
> issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3,
> masterKeyId=8)
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
> 172.31.116.52:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
> issueDate=1548361801965, maxDate=1548966601965, sequenceNumber=5,
> masterKeyId=17)
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: Getting new token from
> https://busbey-training-4.gce.cloudera.com:16000/kms/v1/,
> renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
> kms-dt, Service: 172.31.116.50:16000, Ident: (kms-dt owner=systest,
> renewer=yarn, realUser=, issueDate=1548361802363, maxDate=1548966602363,
> sequenceNumber=6, masterKeyId=18))
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
> 172.31.116.50:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
> issueDate=1548361802363, maxDate=1548966602363, sequenceNumber=6,
> masterKeyId=18)
> 19/01/24 12:30:02 INFO mapreduce.JobResourceUploader: Disabling Erasure
> Coding for path: /user/systest/.staging/job_1548349234632_0003
> 19/01/24 12:30:03 INFO mapreduce.JobSubmitter: Cleaning up the staging area
> /user/systest/.staging/job_1548349234632_0003
> Exception in thread "main" java.lang.IllegalArgumentException: Illegal first
> character <45> at 0. User-space table qualifiers can only start with
> 'alphanumeric characters' from any language: -?
> at
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:193)
> at
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:156)
> at org.apache.hadoop.hbase.TableName.(TableName.java:346)
> at
> org.apache.hadoop.hbase.TableName.createTableNameIfNecessary(TableName.java:382)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:469)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormat.initialize(TableInputFormat.java:198)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.getSplits(TableInputFormatBase.java:243)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormat.getSplits(TableInputFormat.java:254)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:310)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:327)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:200)
> at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1570)
> at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1567)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Su
[jira] [Commented] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751948#comment-16751948
]
Hadoop QA commented on HBASE-21771:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}132m 49s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}143m 58s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncTableGetMultiThreaded |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21771 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956273/hbase-21771.master.002.patch
|
| Optional Tests | dupname asflicense javac javadoc unit |
| uname | Linux d957ef8b9caa 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct
31 10:55:11 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 / 91dffb043a |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/15731/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/15731/testReport/ |
| Max. process+thread count | 5130 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15731/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 3.0.0, 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch,
> hbase-21771.master.002.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS
[jira] [Updated] (HBASE-21781) list_deadservers elapsed time is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqinya updated HBASE-21781:
Attachment: HBASE-21781.branch-1.4.0001.patch
Status: Patch Available (was: Open)
> list_deadservers elapsed time is incorrect
> --
>
> Key: HBASE-21781
> URL: https://issues.apache.org/jira/browse/HBASE-21781
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.4.9
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21781.branch-1.4.0001.patch
>
>
> HBASE-18131 add list_deadservers and clear_deadservers shell. In branch-1.4,
> list_deadservers elapsed time is incorrect. As follows,
> {code:java}
> hbase(main):006:0> list_deadservers
> SERVERNAME
> 0 row(s) in 1548384431.9810 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21781) list_deadservers elapsed time is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751940#comment-16751940
]
xuqinya commented on HBASE-21781:
-
output apply patch
{code:java}
hbase(main):001:0> list_deadservers
SERVERNAME
0 row(s) in 0.2420 seconds
{code}
> list_deadservers elapsed time is incorrect
> --
>
> Key: HBASE-21781
> URL: https://issues.apache.org/jira/browse/HBASE-21781
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.4.9
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21781.branch-1.4.0001.patch
>
>
> HBASE-18131 add list_deadservers and clear_deadservers shell. In branch-1.4,
> list_deadservers elapsed time is incorrect. As follows,
> {code:java}
> hbase(main):006:0> list_deadservers
> SERVERNAME
> 0 row(s) in 1548384431.9810 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21713) Support set region server throttle quota
[ https://issues.apache.org/jira/browse/HBASE-21713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-21713: --- Release Note: Support set region server rpc throttle quota which represents the read/write ability of region servers and throttles when region server's total requests exceeding the limit. Use the following shell command to set RS quota: set_quota TYPE => THROTTLE, REGIONSERVER => 'all', THROTTLE_TYPE => WRITE, LIMIT => '2req/sec' set_quota TYPE => THROTTLE, REGIONSERVER => 'all', LIMIT => NONE "all" represents the throttle quota of all region servers and setting specified region server quota isn't supported currently. > Support set region server throttle quota > > > Key: HBASE-21713 > URL: https://issues.apache.org/jira/browse/HBASE-21713 > Project: HBase > Issue Type: Sub-task >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21713.master.001.patch, > HBASE-21713.master.002.patch, HBASE-21713.master.002.patch, > HBASE-21713.master.003.patch, HBASE-21713.master.004.patch > > > Support set region server throttle quota which represents the read/write > ability of region servers. > Use the following command to set RS quota: > set_quota TYPE => THROTTLE, REGIONSERVER => 'all', THROTTLE_TYPE => WRITE, > LIMIT => '2req/sec' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21713) Support set region server throttle quota
[ https://issues.apache.org/jira/browse/HBASE-21713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-21713: --- Release Note: Support set region server rpc throttle quota which represents the read/write ability of region servers and throttles when region server's total requests exceeding the limit. Use the following shell command to set RS quota: set_quota TYPE => THROTTLE, REGIONSERVER => 'all', THROTTLE_TYPE => WRITE, LIMIT => '2req/sec' set_quota TYPE => THROTTLE, REGIONSERVER => 'all', LIMIT => NONE "all" represents the throttle quota of all region servers and setting specified region server quota isn't supported currently. was: Support set region server rpc throttle quota which represents the read/write ability of region servers and throttles when region server's total requests exceeding the limit. Use the following shell command to set RS quota: set_quota TYPE => THROTTLE, REGIONSERVER => 'all', THROTTLE_TYPE => WRITE, LIMIT => '2req/sec' set_quota TYPE => THROTTLE, REGIONSERVER => 'all', LIMIT => NONE "all" represents the throttle quota of all region servers and setting specified region server quota isn't supported currently. > Support set region server throttle quota > > > Key: HBASE-21713 > URL: https://issues.apache.org/jira/browse/HBASE-21713 > Project: HBase > Issue Type: Sub-task >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21713.master.001.patch, > HBASE-21713.master.002.patch, HBASE-21713.master.002.patch, > HBASE-21713.master.003.patch, HBASE-21713.master.004.patch > > > Support set region server throttle quota which represents the read/write > ability of region servers. > Use the following command to set RS quota: > set_quota TYPE => THROTTLE, REGIONSERVER => 'all', THROTTLE_TYPE => WRITE, > LIMIT => '2req/sec' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21764) Size of in-memory compaction thread pool shoud be configurable
[
https://issues.apache.org/jira/browse/HBASE-21764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751937#comment-16751937
]
Zheng Hu commented on HBASE-21764:
--
Ping [~Apache9]
> Size of in-memory compaction thread pool shoud be configurable
> --
>
> Key: HBASE-21764
> URL: https://issues.apache.org/jira/browse/HBASE-21764
> Project: HBase
> Issue Type: Sub-task
> Components: in-memory-compaction
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21764.v1.patch, HBASE-21764.v2.patch,
> HBASE-21764.v3.patch
>
>
> In RegionServicesForStores, we can see :
> {code}
> private static final int POOL_SIZE = 10;
> private static final ThreadPoolExecutor INMEMORY_COMPACTION_POOL =
> new ThreadPoolExecutor(POOL_SIZE, POOL_SIZE, 60, TimeUnit.SECONDS,
> new LinkedBlockingQueue<>(),
> new ThreadFactory() {
> @Override
> public Thread newThread(Runnable r) {
> String name = Thread.currentThread().getName() +
> "-inmemoryCompactions-" +
> System.currentTimeMillis();
> return new Thread(r, name);
> }
> });
> {code}
> The pool size should be configurable, because if many regions on a rs, the
> default 10 threads will be not enough.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21781) list_deadservers elapsed time is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqinya updated HBASE-21781:
Description:
HBASE-18131 add list_deadservers and clear_deadservers shell. In branch-1.4,
list_deadservers elapsed time is incorrect. As follows,
{code:java}
hbase(main):006:0> list_deadservers
SERVERNAME
0 row(s) in 1548384431.9810 seconds
{code}
was:
list_deadservers elapsed time is incorrect.As follows,
{code:java}
hbase(main):006:0> list_deadservers
SERVERNAME
0 row(s) in 1548384431.9810 seconds
{code}
> list_deadservers elapsed time is incorrect
> --
>
> Key: HBASE-21781
> URL: https://issues.apache.org/jira/browse/HBASE-21781
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.4.9
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21781.branch-1.4.0001.patch
>
>
> HBASE-18131 add list_deadservers and clear_deadservers shell. In branch-1.4,
> list_deadservers elapsed time is incorrect. As follows,
> {code:java}
> hbase(main):006:0> list_deadservers
> SERVERNAME
> 0 row(s) in 1548384431.9810 seconds
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21729) Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-21729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-21729: - Resolution: Resolved Status: Resolved (was: Patch Available) > Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from > CoordinatedStateManager > - > > Key: HBASE-21729 > URL: https://issues.apache.org/jira/browse/HBASE-21729 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21729.branch-2.001.patch, > HBASE-21729.master.001.patch, HBASE-21729.master.002.patch, > HBASE-21729.master.003.patch > > > If procedureV2 based WAL splitting is enabled, CoordinatedStateManager will > not be initialized and will be useless when we switch to procedureV2 WAL > splitting. To remove this class in the futrue, we need to extract > getProcedureMemberRpcs() and getProcedureCoordinatorRpcs(), which are > actually not related to WAL splitting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21729) Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-21729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751936#comment-16751936 ] Jingyun Tian commented on HBASE-21729: -- Pushed to master and branch-2, thanks [~zghaobac] for reviewing. > Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from > CoordinatedStateManager > - > > Key: HBASE-21729 > URL: https://issues.apache.org/jira/browse/HBASE-21729 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21729.branch-2.001.patch, > HBASE-21729.master.001.patch, HBASE-21729.master.002.patch, > HBASE-21729.master.003.patch > > > If procedureV2 based WAL splitting is enabled, CoordinatedStateManager will > not be initialized and will be useless when we switch to procedureV2 WAL > splitting. To remove this class in the futrue, we need to extract > getProcedureMemberRpcs() and getProcedureCoordinatorRpcs(), which are > actually not related to WAL splitting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21745) Make HBCK2 be able to fix issues other than region assignment
[
https://issues.apache.org/jira/browse/HBASE-21745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751933#comment-16751933
]
stack commented on HBASE-21745:
---
Doing review of hbck1 to see what applies still and what to bring over so works
against new guise.
> Make HBCK2 be able to fix issues other than region assignment
> -
>
> Key: HBASE-21745
> URL: https://issues.apache.org/jira/browse/HBASE-21745
> Project: HBase
> Issue Type: Umbrella
> Components: hbase-operator-tools, hbck2
>Reporter: Duo Zhang
>Assignee: stack
>Priority: Critical
>
> This is what [~apurtell] posted on mailing-list, HBCK2 should support
> {quote}
>- Rebuild meta from region metadata in the filesystem, aka offline meta
>rebuild.
>- Fix assignment errors (undeployed regions, double assignments (yes,
>should not be possible), etc)
>- Fix region holes, overlaps, and other errors in the region chain
>- Fix failed split and merge transactions that have failed to roll back
>due to some bug (related to previous)
>- Enumerate store files to determine file level corruption and sideline
>corrupt files
>- Fix hfile link problems (dangling / broken)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21781) list_deadservers elapsed time is incorrect
xuqinya created HBASE-21781:
---
Summary: list_deadservers elapsed time is incorrect
Key: HBASE-21781
URL: https://issues.apache.org/jira/browse/HBASE-21781
Project: HBase
Issue Type: Bug
Components: shell
Affects Versions: 1.4.9
Reporter: xuqinya
Assignee: xuqinya
list_deadservers elapsed time is incorrect.As follows,
{code:java}
hbase(main):006:0> list_deadservers
SERVERNAME
0 row(s) in 1548384431.9810 seconds
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (HBASE-21745) Make HBCK2 be able to fix issues other than region assignment
[
https://issues.apache.org/jira/browse/HBASE-21745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-21745 started by stack.
-
> Make HBCK2 be able to fix issues other than region assignment
> -
>
> Key: HBASE-21745
> URL: https://issues.apache.org/jira/browse/HBASE-21745
> Project: HBase
> Issue Type: Umbrella
> Components: hbase-operator-tools, hbck2
>Reporter: Duo Zhang
>Assignee: stack
>Priority: Critical
>
> This is what [~apurtell] posted on mailing-list, HBCK2 should support
> {quote}
>- Rebuild meta from region metadata in the filesystem, aka offline meta
>rebuild.
>- Fix assignment errors (undeployed regions, double assignments (yes,
>should not be possible), etc)
>- Fix region holes, overlaps, and other errors in the region chain
>- Fix failed split and merge transactions that have failed to roll back
>due to some bug (related to previous)
>- Enumerate store files to determine file level corruption and sideline
>corrupt files
>- Fix hfile link problems (dangling / broken)
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21729) Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from CoordinatedStateManager
[
https://issues.apache.org/jira/browse/HBASE-21729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751924#comment-16751924
]
Hadoop QA commented on HBASE-21729:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} 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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
7s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
56s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
37s{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
21s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 50s{color}
| {color:red} hbase-server generated 2 new + 186 unchanged - 2 fixed = 188
total (was 188) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
3s{color} | {color:green} hbase-server: The patch generated 0 new + 0
unchanged - 2 fixed = 0 total (was 2) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
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}
8m 23s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}126m
53s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
27s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}163m 24s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-21729 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956266/HBASE-21729.branch-2.001.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 2243d5003814 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | branch-2 / de31d56c2d |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| javac |
https://builds.apache.org/job/PreCommit-HBASE-Build/15728/artifact/patchprocess/diff-compile-javac-hbase-server.txt
[jira] [Commented] (HBASE-21636) Enhance the shell scan command to support missing scanner specifications like ReadType, IsolationLevel etc.
[
https://issues.apache.org/jira/browse/HBASE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751922#comment-16751922
]
Nihal Jain commented on HBASE-21636:
[~zghaobac] Could you please review this?
> Enhance the shell scan command to support missing scanner specifications like
> ReadType, IsolationLevel etc.
> ---
>
> Key: HBASE-21636
> URL: https://issues.apache.org/jira/browse/HBASE-21636
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 3.0.0, 2.0.0, 2.1.2
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Attachments: HBASE-21636.master.001.patch,
> HBASE-21636.master.002.patch
>
>
> Enhance the shell scan command to support scanner specifications:
> - ReadType
> - IsolationLevel
> - Region replica id
> - Allow partial results
> - Batch
> - Max result size
> Also, make use of \{{limit}} and set it in the scan object to limit the
> number of rows returned by the scanner.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21689) Make table/namespace specific current quota info available in shell(describe_namespace & describe)
[
https://issues.apache.org/jira/browse/HBASE-21689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751912#comment-16751912
]
Guanghao Zhang commented on HBASE-21689:
+1. Let me commit it. Thanks [~jatsakthi] for contributing.
> Make table/namespace specific current quota info available in
> shell(describe_namespace & describe)
> --
>
> Key: HBASE-21689
> URL: https://issues.apache.org/jira/browse/HBASE-21689
> Project: HBase
> Issue Type: Improvement
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Attachments: hbase-21689.master.001.patch,
> hbase-21689.master.002.patch, hbase-21689.master.003.patch
>
>
> describe_namespace & describe command in shell should show current quota(if
> present) on the particular table/namespace.
> {noformat}
> // Namespace
> hbase(main):002:0> create_namespace 'ns1',
> {'hbase.namespace.quota.maxtables'=>'5'}
> Took 0.1703 seconds
> hbase(main):004:0> set_quota TYPE => SPACE, NAMESPACE => 'ns1', LIMIT =>
> '50T', POLICY => NO_WRITES
> Took 0.0644 seconds
> hbase(main):007:0> set_quota TYPE => THROTTLE, NAMESPACE => 'ns1', LIMIT =>
> '10m/sec'
> Took 0.0271 seconds
> hbase(main):005:0> describe_namespace 'ns1'
> DESCRIPTION
> {NAME => 'ns1', hbase.namespace.quota.maxtables => '5'}
> // Table
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't1', LIMIT => '1G',
> POLICY => NO_INSERTS
> Took 0.0155 seconds
> hbase(main):009:0> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT =>
> '10T/hour'
> Took 0.0309 seconds
> hbase(main):008:0> describe 't1'
> Table t1 is ENABLED
> t1
> COLUMN FAMILIES DESCRIPTION
> {NAME => 'cf', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false',
> NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS
> => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE',
> TTL => 'FOREVER', MIN_VERSIONS => '0', REPL
> ICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false',
> IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRI
> TE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE',
> BLOCKCACHE => 'true', BLOCKSIZE => '65536'}
> 1 row(s)
> Took 0.0341 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[
https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751908#comment-16751908
]
Hadoop QA commented on HBASE-21780:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} HBASE-21780 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-21780 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15732/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
> --
>
> Key: HBASE-21780
> URL: https://issues.apache.org/jira/browse/HBASE-21780
> Project: HBase
> Issue Type: Improvement
> Components: UI, Usability
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Attachments: RS_ZKQuorum.png, RS_ZKQuorum_afterPatch.png,
> hbase-21780.master.001.patch
>
>
> HBASE-8812 made this change for MasterUI but not for RegionServer UI.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21775) The BufferedMutator doesn't ever refresh region location cache
[
https://issues.apache.org/jira/browse/HBASE-21775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751907#comment-16751907
]
stack commented on HBASE-21775:
---
Patch looks good [~tommyzli] Why would tablename be null do you think? What
version of hbase are you running?
> The BufferedMutator doesn't ever refresh region location cache
> --
>
> Key: HBASE-21775
> URL: https://issues.apache.org/jira/browse/HBASE-21775
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Tommy Li
>Assignee: Tommy Li
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21775.master.001.patch
>
>
> {color:#22}I noticed in some of my writing jobs that the BufferedMutator
> would get stuck retrying writes against a dead server.{color}
> {code:java}
> 19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:15:54 WARN [htable-pool3-t56] client.AsyncRequestFutureImpl:
> id=2, table=dummy_table, attempt=15/21, failureCount=1ops, last
> exception=org.apache.hadoop.hbase.DoNotRetryIOException: Operation rpcTimeout
> on ,17020,1547848193782, tracking started Fri Jan 18 14:55:37 PST
> 2019; NOT retrying, failed=1 -- final attempt!
> 19/01/18 15:15:54 ERROR [Executor task launch worker for task 0]
> IngestRawData.map(): [B@258bc2c7:
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: Operation rpcTimeout: 1 time, servers with issues:
> ,17020,1547848193782
> {code}
>
> After the single remaining action permanently failed, it would resume
> progress only to get stuck again retrying against the same dead server:
> {code:java}
> 19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:21:20 INFO [htable-pool3-t55] client.AsyncRequestFutureImpl:
> id=2, table=dummy_table, attempt=6/21, failureCount=1ops, last
> exception=java.net.ConnectException: Call to failed on connection
> exception:
> org.apache.hbase.thirdparty.io.netty.channel.ConnectTimeoutException:
> connection timed out: on ,17020,1547848193782, tracking
> started null, retrying after=20089ms, operationsToReplay=1
> {code}
>
> Only restarting the client process to generate a new BufferedMutator instance
> would fix the issue, at least until the next regionserver crash
> The logs I've pasted show the issue happening with a
> ConnectionTimeoutException, but we've also seen it with
> NotServingRegionException and some others
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Attachment: RS_ZKQuorum_afterPatch.png > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png, RS_ZKQuorum_afterPatch.png, > hbase-21780.master.001.patch > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Status: Patch Available (was: In Progress) > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement > Components: UI, Usability >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png, RS_ZKQuorum_afterPatch.png, > hbase-21780.master.001.patch > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-8812) Avoid a wide line on the HMaster webUI if we have many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-8812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751906#comment-16751906 ] Sakthi commented on HBASE-8812: --- Have filed HBASE-21780 related to this. (same issue with RegionServer UI). Interested folks can review the patch there. Thanks :) > Avoid a wide line on the HMaster webUI if we have many ZooKeeper servers > > > Key: HBASE-8812 > URL: https://issues.apache.org/jira/browse/HBASE-8812 > Project: HBase > Issue Type: Improvement > Components: master >Affects Versions: 0.94.8 >Reporter: Fengdong Yu >Assignee: Fengdong Yu >Priority: Minor > Fix For: 0.98.0, 0.95.2 > > Attachments: HBASE-8812.patch, screeshot.PNG > > > add a line break for every four zookeeper quorums on the HMaster webUI. > I don't think this need a test case. just manual testing is enough. I've > tested on my testing cluster. everything works well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Component/s: Usability UI > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement > Components: UI, Usability >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png, RS_ZKQuorum_afterPatch.png, > hbase-21780.master.001.patch > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751904#comment-16751904 ] Sakthi commented on HBASE-21780: Have submitted a patch for the master branch. Along with a screenshot of how the UI looks after the patch. > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png, RS_ZKQuorum_afterPatch.png, > hbase-21780.master.001.patch > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Attachment: hbase-21780.master.001.patch > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png, hbase-21780.master.001.patch > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20215) Rename CollectionUtils to ConcurrentMapUtils
[
https://issues.apache.org/jira/browse/HBASE-20215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-20215:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.2.0
3.0.0
Status: Resolved (was: Patch Available)
Pushed to branch-2+ after getting one of the checkstyles at least Thanks
for patch [~wchevreuil]
> Rename CollectionUtils to ConcurrentMapUtils
>
>
> Key: HBASE-20215
> URL: https://issues.apache.org/jira/browse/HBASE-20215
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: BELUGA BEHR
>Assignee: Wellington Chevreuil
>Priority: Trivial
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-20215-master.001.patch,
> HBASE-20215-master.002.patch
>
>
> After [HBASE-19488] is complete, rename the class {{CollectionUtils}} to
> {{ConcurrentMapUtils}} because the only remaining methods are geared for the
> {{ConcurrentMap}} class. It will prevent name collisions with the popular
> Apache Commons {{CollectionUtils}} in the code base.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-21603) Move access control service from regionserver to master
[ https://issues.apache.org/jira/browse/HBASE-21603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei resolved HBASE-21603. Resolution: Won't Fix Split the task into several tasks, see HBASE-21739. > Move access control service from regionserver to master > --- > > Key: HBASE-21603 > URL: https://issues.apache.org/jira/browse/HBASE-21603 > Project: HBase > Issue Type: Sub-task >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > > Create a sub task to move access control service from regionserver to master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21771:
---
Attachment: hbase-21771.master.002.patch
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 3.0.0, 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch,
> hbase-21771.master.002.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751882#comment-16751882
]
Sakthi commented on HBASE-21771:
I think a rebase was required. Have uploaded a new patch.
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 3.0.0, 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch,
> hbase-21771.master.002.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21771:
---
Fix Version/s: (was: 3.0.0)
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 3.0.0, 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751872#comment-16751872
]
Sakthi commented on HBASE-21771:
Weird. The patch applies cleanly on my master branch though.
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 3.0.0, 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 3.0.0, 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21689) Make table/namespace specific current quota info available in shell(describe_namespace & describe)
[
https://issues.apache.org/jira/browse/HBASE-21689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751877#comment-16751877
]
Sakthi commented on HBASE-21689:
Ping [~zghaobac]. Also [~elserj], if you would like to have a look as well. :)
> Make table/namespace specific current quota info available in
> shell(describe_namespace & describe)
> --
>
> Key: HBASE-21689
> URL: https://issues.apache.org/jira/browse/HBASE-21689
> Project: HBase
> Issue Type: Improvement
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Attachments: hbase-21689.master.001.patch,
> hbase-21689.master.002.patch, hbase-21689.master.003.patch
>
>
> describe_namespace & describe command in shell should show current quota(if
> present) on the particular table/namespace.
> {noformat}
> // Namespace
> hbase(main):002:0> create_namespace 'ns1',
> {'hbase.namespace.quota.maxtables'=>'5'}
> Took 0.1703 seconds
> hbase(main):004:0> set_quota TYPE => SPACE, NAMESPACE => 'ns1', LIMIT =>
> '50T', POLICY => NO_WRITES
> Took 0.0644 seconds
> hbase(main):007:0> set_quota TYPE => THROTTLE, NAMESPACE => 'ns1', LIMIT =>
> '10m/sec'
> Took 0.0271 seconds
> hbase(main):005:0> describe_namespace 'ns1'
> DESCRIPTION
> {NAME => 'ns1', hbase.namespace.quota.maxtables => '5'}
> // Table
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't1', LIMIT => '1G',
> POLICY => NO_INSERTS
> Took 0.0155 seconds
> hbase(main):009:0> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT =>
> '10T/hour'
> Took 0.0309 seconds
> hbase(main):008:0> describe 't1'
> Table t1 is ENABLED
> t1
> COLUMN FAMILIES DESCRIPTION
> {NAME => 'cf', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false',
> NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS
> => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE',
> TTL => 'FOREVER', MIN_VERSIONS => '0', REPL
> ICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false',
> IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRI
> TE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE',
> BLOCKCACHE => 'true', BLOCKSIZE => '65536'}
> 1 row(s)
> Took 0.0341 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21744) timeout for server list refresh calls
[
https://issues.apache.org/jira/browse/HBASE-21744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751871#comment-16751871
]
Hadoop QA commented on HBASE-21744:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
52s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
20s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
33s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
48s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m
1s{color} | {color:red} hbase-server: The patch generated 1 new + 91 unchanged
- 0 fixed = 92 total (was 91) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
50s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
12m 32s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
12s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}136m
41s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
39s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}212m 39s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21744 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956223/HBASE-21744.01.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux cd15bec511cb 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct
31 10:55:11 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/d
[jira] [Commented] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751865#comment-16751865 ] Sakthi commented on HBASE-21780: I have attached a screenshot of how the RegionServer UI looks (with a wider cell - zk quorum) when the count of zookeeper servers increases. > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-21780 started by Sakthi. -- > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Attachment: RS_ZKQuorum.png > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > Attachments: RS_ZKQuorum.png > > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Attachment: (was: RS_Cluster Key.png) > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
[ https://issues.apache.org/jira/browse/HBASE-21780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sakthi updated HBASE-21780: --- Attachment: RS_Cluster Key.png > Avoid a wide line on the RegionServer webUI for many ZooKeeper servers > -- > > Key: HBASE-21780 > URL: https://issues.apache.org/jira/browse/HBASE-21780 > Project: HBase > Issue Type: Improvement >Reporter: Sakthi >Assignee: Sakthi >Priority: Minor > > HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21739) Move grant/revoke from regionserver to master
[ https://issues.apache.org/jira/browse/HBASE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751862#comment-16751862 ] Yi Mei commented on HBASE-21739: Most of the failed UT are not related. Fix checkstyle and attach the patch again. > Move grant/revoke from regionserver to master > - > > Key: HBASE-21739 > URL: https://issues.apache.org/jira/browse/HBASE-21739 > Project: HBase > Issue Type: Sub-task >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21739.master.001.patch, > HBASE-21739.master.002.patch, HBASE-21739.master.003.patch > > > Create a sub-task to move grant/revoke from regionserver to master. Other > access control operations(getUserPermissions/ checkPermissions/ > hasPermission) will be moved in another sub-task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21739) Move grant/revoke from regionserver to master
[ https://issues.apache.org/jira/browse/HBASE-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-21739: --- Attachment: HBASE-21739.master.003.patch > Move grant/revoke from regionserver to master > - > > Key: HBASE-21739 > URL: https://issues.apache.org/jira/browse/HBASE-21739 > Project: HBase > Issue Type: Sub-task >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21739.master.001.patch, > HBASE-21739.master.002.patch, HBASE-21739.master.003.patch > > > Create a sub-task to move grant/revoke from regionserver to master. Other > access control operations(getUserPermissions/ checkPermissions/ > hasPermission) will be moved in another sub-task. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21780) Avoid a wide line on the RegionServer webUI for many ZooKeeper servers
Sakthi created HBASE-21780: -- Summary: Avoid a wide line on the RegionServer webUI for many ZooKeeper servers Key: HBASE-21780 URL: https://issues.apache.org/jira/browse/HBASE-21780 Project: HBase Issue Type: Improvement Reporter: Sakthi Assignee: Sakthi HBASE-8812 made this change for MasterUI but not for RegionServer UI. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21771:
---
Attachment: (was: Screen Shot 2019-01-24 at 7.32.35 PM.png)
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21771:
---
Fix Version/s: 3.0.0
Affects Version/s: 3.0.0
Status: Patch Available (was: Open)
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 2.0.0, 2.1.0, 3.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 3.0.0, 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21713) Support set region server throttle quota
[ https://issues.apache.org/jira/browse/HBASE-21713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751858#comment-16751858 ] Guanghao Zhang commented on HBASE-21713: Let me commit it. [~Yi Mei] Please add a release note. Thanks for contributing. > Support set region server throttle quota > > > Key: HBASE-21713 > URL: https://issues.apache.org/jira/browse/HBASE-21713 > Project: HBase > Issue Type: Sub-task >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Attachments: HBASE-21713.master.001.patch, > HBASE-21713.master.002.patch, HBASE-21713.master.002.patch, > HBASE-21713.master.003.patch, HBASE-21713.master.004.patch > > > Support set region server throttle quota which represents the read/write > ability of region servers. > Use the following command to set RS quota: > set_quota TYPE => THROTTLE, REGIONSERVER => 'all', THROTTLE_TYPE => WRITE, > LIMIT => '2req/sec' -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751857#comment-16751857
]
Hadoop QA commented on HBASE-21771:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 7s{color}
| {color:red} HBASE-21771 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-21771 |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15729/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 3.0.0, 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 3.0.0, 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751852#comment-16751852
]
Sakthi edited comment on HBASE-21771 at 1/25/19 3:36 AM:
-
The issue prevails in master branch as well. Here's a patch for the master
branch.
was (Author: jatsakthi):
The issue prevails in master as well. Here's a patch for the master
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 3.0.0, 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 3.0.0, 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751854#comment-16751854
]
Sakthi commented on HBASE-21771:
Have attached a screenshot of how the UI looks now. Also the copy/paste of the
cluster-key worked while trying to add peer. [~busbey], let me know your
thoughts :)
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21771:
---
Attachment: ClusterKey_afterPatch.png
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: ClusterKey_afterPatch.png, hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21771:
---
Attachment: Screen Shot 2019-01-24 at 7.32.35 PM.png
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21729) Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-21729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-21729: - Attachment: HBASE-21729.branch-2.001.patch > Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from > CoordinatedStateManager > - > > Key: HBASE-21729 > URL: https://issues.apache.org/jira/browse/HBASE-21729 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21729.branch-2.001.patch, > HBASE-21729.master.001.patch, HBASE-21729.master.002.patch, > HBASE-21729.master.003.patch > > > If procedureV2 based WAL splitting is enabled, CoordinatedStateManager will > not be initialized and will be useless when we switch to procedureV2 WAL > splitting. To remove this class in the futrue, we need to extract > getProcedureMemberRpcs() and getProcedureCoordinatorRpcs(), which are > actually not related to WAL splitting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21771:
---
Attachment: hbase-21771.master.001.patch
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21771) Cluster key in Master UI is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751852#comment-16751852
]
Sakthi commented on HBASE-21771:
The issue prevails in master as well. Here's a patch for the master
> Cluster key in Master UI is incorrect
> -
>
> Key: HBASE-21771
> URL: https://issues.apache.org/jira/browse/HBASE-21771
> Project: HBase
> Issue Type: Bug
> Components: Replication, UI, Usability
>Affects Versions: 2.1.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.1.3
>
> Attachments: hbase-21771.master.001.patch
>
>
> The master UI is supposed to give us a cluster key we can copy/paste to add a
> replication peer in the hbase shell. the shell explains that it should look
> like this:
> {quote}
> {code}
> For a HBase cluster peer, a cluster key must be provided and is composed like
> this:
> hbase.zookeeper.quorum:hbase.zookeeper.property.clientPort:zookeeper.znode.parent
> This gives a full path for HBase to connect to another HBase cluster.
> ...
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "ENABLED"
> hbase> add_peer '1', CLUSTER_KEY => "server1.cie.com:2181:/hbase", STATE =>
> "DISABLED"
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> TABLE_CFS => { "table1" => [], "table2" => ["cf1"], "table3" => ["cf1",
> "cf2"] }
> hbase> add_peer '2', CLUSTER_KEY => "zk1,zk2,zk3:2182:/hbase-prod",
> NAMESPACES => ["ns1", "ns2", "ns3"]
> {code}
> {quote}
> However, on my example cluster with ZK quorum with 3 servers, the master ui
> gives this:
> {quote}
> {code}
> Cluster Key busbey-training-1.gce.cloudera.com:2181
> busbey-training-2.gce.cloudera.com:2181
> busbey-training-3.gce.cloudera.com:2181:/hbaseKey to add this cluster
> as a peer for replication. Use 'help "add_peer"' in the shell for details.
> {code}
> {quote}
> Note that the quorum members are newline separated instead of comma and that
> the port appears on each member instead of after the set of host names.
> Workaround is to manually construct the cluster key from the details in the
> field. :(
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21585) Use ConnectionImplementation instead of ClusterConnection for sync client implementation
[ https://issues.apache.org/jira/browse/HBASE-21585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21585: -- Status: Open (was: Patch Available) The current patch is stale. Will upload new patch after related issues are done. > Use ConnectionImplementation instead of ClusterConnection for sync client > implementation > > > Key: HBASE-21585 > URL: https://issues.apache.org/jira/browse/HBASE-21585 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21585-HBASE-21512-v1.patch, > HBASE-21585-HBASE-21512-v2.patch, HBASE-21585-HBASE-21512.patch > > > So we can remove lots of method declarations in ClusterConnection, if they > are only used by sync client implementation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21779) Reimplement SecureBulkLoadClient to use AsyncClusterConnection
Duo Zhang created HBASE-21779: - Summary: Reimplement SecureBulkLoadClient to use AsyncClusterConnection Key: HBASE-21779 URL: https://issues.apache.org/jira/browse/HBASE-21779 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang So we will not rely on the RpcRetryingCaller and ServiceCallable any more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21770) Should deal with meta table in HRegionLocator.getAllRegionLocations
[ https://issues.apache.org/jira/browse/HBASE-21770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21770: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master and branch-2. Thanks [~zghaobac] for reviewing. > Should deal with meta table in HRegionLocator.getAllRegionLocations > --- > > Key: HBASE-21770 > URL: https://issues.apache.org/jira/browse/HBASE-21770 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-21770.patch > > > Missed this one is UT. Let me add the support and also a UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21778) Remove the usage of the locateRegion related methods in ClusterConnection
Duo Zhang created HBASE-21778: - Summary: Remove the usage of the locateRegion related methods in ClusterConnection Key: HBASE-21778 URL: https://issues.apache.org/jira/browse/HBASE-21778 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang As now RegionLocator can give you everything. So later we could remove the ClusterConnection completely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21729) Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-21729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751840#comment-16751840 ] Guanghao Zhang commented on HBASE-21729: +1 > Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from > CoordinatedStateManager > - > > Key: HBASE-21729 > URL: https://issues.apache.org/jira/browse/HBASE-21729 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21729.master.001.patch, > HBASE-21729.master.002.patch, HBASE-21729.master.003.patch > > > If procedureV2 based WAL splitting is enabled, CoordinatedStateManager will > not be initialized and will be useless when we switch to procedureV2 WAL > splitting. To remove this class in the futrue, we need to extract > getProcedureMemberRpcs() and getProcedureCoordinatorRpcs(), which are > actually not related to WAL splitting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21777) "Tune compaction throughput" debug messages even when nothing has changed
Andrew Purtell created HBASE-21777: -- Summary: "Tune compaction throughput" debug messages even when nothing has changed Key: HBASE-21777 URL: https://issues.apache.org/jira/browse/HBASE-21777 Project: HBase Issue Type: Bug Affects Versions: 1.5.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 1.5.0 PressureAwareCompactionThroughputController will log "tune compaction throughput" debug messages even when after consideration the re-tuning makes no change to current settings. In that case it would be better not to log anything. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21776) Duplicate "Set storagePolicy" debug logging
Andrew Purtell created HBASE-21776: -- Summary: Duplicate "Set storagePolicy" debug logging Key: HBASE-21776 URL: https://issues.apache.org/jira/browse/HBASE-21776 Project: HBase Issue Type: Bug Affects Versions: 1.5.0 Reporter: Andrew Purtell Assignee: Andrew Purtell Fix For: 1.5.0 An example: 2019-01-25 02:57:15,831 DEBUG [regionserver/ip-172-31-13-83.us-west-2.compute.internal/172.31.13.83:8120-longCompactions-1548384634805] util.CommonFSUtils: Set storagePolicy=HOT for path=hdfs://ip-172-31-5-95.us-west-2.compute.internal:8020/hbase/data/default/IntegrationTestBigLinkedList/16899cdfdb4ab217208f4108ad0c4803/.tmp/meta 2019-01-25 02:57:15,831 DEBUG [regionserver/ip-172-31-13-83.us-west-2.compute.internal/172.31.13.83:8120-longCompactions-1548384634805] util.CommonFSUtils: Set storagePolicy=HOT for path=hdfs://ip-172-31-5-95.us-west-2.compute.internal:8020/hbase/data/default/IntegrationTestBigLinkedList/16899cdfdb4ab217208f4108ad0c4803/.tmp/meta Seen most often during compactions. Ideally we only log once per directory per flush or compaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751832#comment-16751832
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #68 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/68/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/68//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/68//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/68//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21729) Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from CoordinatedStateManager
[ https://issues.apache.org/jira/browse/HBASE-21729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751824#comment-16751824 ] Jingyun Tian commented on HBASE-21729: -- These two Javac warnings are introduced by Netty Connections. They are not related to this patch. > Extract ProcedureCoordinatorRpcs and ProcedureMemberRpcs from > CoordinatedStateManager > - > > Key: HBASE-21729 > URL: https://issues.apache.org/jira/browse/HBASE-21729 > Project: HBase > Issue Type: Sub-task >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Attachments: HBASE-21729.master.001.patch, > HBASE-21729.master.002.patch, HBASE-21729.master.003.patch > > > If procedureV2 based WAL splitting is enabled, CoordinatedStateManager will > not be initialized and will be useless when we switch to procedureV2 WAL > splitting. To remove this class in the futrue, we need to extract > getProcedureMemberRpcs() and getProcedureCoordinatorRpcs(), which are > actually not related to WAL splitting. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21770) Should deal with meta table in HRegionLocator.getAllRegionLocations
[ https://issues.apache.org/jira/browse/HBASE-21770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751806#comment-16751806 ] Guanghao Zhang commented on HBASE-21770: +1 > Should deal with meta table in HRegionLocator.getAllRegionLocations > --- > > Key: HBASE-21770 > URL: https://issues.apache.org/jira/browse/HBASE-21770 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-21770.patch > > > Missed this one is UT. Let me add the support and also a UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21770) Should deal with meta table in HRegionLocator.getAllRegionLocations
[ https://issues.apache.org/jira/browse/HBASE-21770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21770: -- Fix Version/s: 2.2.0 3.0.0 > Should deal with meta table in HRegionLocator.getAllRegionLocations > --- > > Key: HBASE-21770 > URL: https://issues.apache.org/jira/browse/HBASE-21770 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-21770.patch > > > Missed this one is UT. Let me add the support and also a UT. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21564) race condition in WAL rolling resulting in size-based rolling getting stuck
[
https://issues.apache.org/jira/browse/HBASE-21564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751791#comment-16751791
]
Hadoop QA commented on HBASE-21564:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
38s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
49s{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
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s{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
36s{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 44s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}134m
13s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 12m
29s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
44s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}193m 13s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21564 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956208/HBASE-21564.06.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 0707505e27b7 4.4.0-138-generic #164~14.04.1-Ubuntu SMP Fri Oct
5 08:56:16 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 / 416b70f461 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8
[jira] [Commented] (HBASE-21735) Port HBASE-18784 (Use of filesystem that requires hflush / hsync / append / etc should query outputstream capabilities) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-21735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751778#comment-16751778
]
Hudson commented on HBASE-21735:
Results for branch branch-1
[build #652 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/652/]:
(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/652//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/652//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/652//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Port HBASE-18784 (Use of filesystem that requires hflush / hsync / append /
> etc should query outputstream capabilities) to branch-1
> ---
>
> Key: HBASE-21735
> URL: https://issues.apache.org/jira/browse/HBASE-21735
> Project: HBase
> Issue Type: Sub-task
> Components: fs, wal
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Major
> Labels: s3
> Fix For: 1.5.0
>
> Attachments: HBASE-21735-branch-1.patch, HBASE-21735-branch-1.patch,
> HBASE-21735-branch-1.patch
>
>
> HBASE-18784 has nice checks for fs capabilities and logged warnings,
> especially useful on recent versions of hadoop. The refactors are minor and
> are compatible with a minor release. Port to branch-1.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-18784) Use of filesystem that requires hflush / hsync / append / etc should query outputstream capabilities
[
https://issues.apache.org/jira/browse/HBASE-18784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751779#comment-16751779
]
Hudson commented on HBASE-18784:
Results for branch branch-1
[build #652 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/652/]:
(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/652//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/652//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/652//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Use of filesystem that requires hflush / hsync / append / etc should query
> outputstream capabilities
>
>
> Key: HBASE-18784
> URL: https://issues.apache.org/jira/browse/HBASE-18784
> Project: HBase
> Issue Type: Improvement
> Components: Filesystem Integration
>Affects Versions: 1.4.0, 2.0.0-alpha-2
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Labels: s3
> Fix For: 2.0.0
>
> Attachments: HBASE-18784-branch-1.v2.patch, HBASE-18784.0.patch,
> HBASE-18784.1.patch, HBASE-18784.2.patch
>
>
> In places where we rely on the underlying filesystem holding up the promises
> of hflush/hsync (most importantly the WAL), we should use the new interfaces
> provided by HDFS-11644 to fail loudly when they are not present (e.g. on S3,
> on EC mounts, etc).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21775) The BufferedMutator doesn't ever refresh region location cache
[
https://issues.apache.org/jira/browse/HBASE-21775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751730#comment-16751730
]
Hadoop QA commented on HBASE-21775:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
28s{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
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
38s{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} 5m
12s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 24s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
23s{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} 3m
17s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
11s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 42m 26s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21775 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956220/HBASE-21775.master.001.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux b60932886172 4.4.0-138-generic #164~14.04.1-Ubuntu SMP Fri Oct
5 08:56:16 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 / 416b70f461 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/15726/testReport/ |
| Max. process+thread count | 265 (vs. ulimit of 1) |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15726/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
[jira] [Updated] (HBASE-21744) timeout for server list refresh calls
[ https://issues.apache.org/jira/browse/HBASE-21744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21744: - Attachment: HBASE-21744.01.patch > timeout for server list refresh calls > -- > > Key: HBASE-21744 > URL: https://issues.apache.org/jira/browse/HBASE-21744 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-21744.01.patch, HBASE-21744.patch > > > Not sure why yet, but we are seeing the case when cluster is in overall a bad > state, where after RS dies and deletes its znode, the notification looks like > it's lost, so the master doesn't detect the failure. ZK itself appears to be > healthy and doesn't report anything special. > After some other change is made to the server list, master rescans the list > and picks up the stale change. Might make sense to add a config that would > trigger the refresh if it hasn't happened for a while (e.g. 1 minute). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21201) Support to run VerifyReplication MR tool without peerid
[
https://issues.apache.org/jira/browse/HBASE-21201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751722#comment-16751722
]
Toshihiro Suzuki commented on HBASE-21201:
--
I modified VerifyReplication to be also able to accept quorumAddress (format is
zk_quorum:zk_port:zk_hbase_path) in the patch. Could you please review it?
[~yuzhih...@gmail.com] [~elserj]
> Support to run VerifyReplication MR tool without peerid
> ---
>
> Key: HBASE-21201
> URL: https://issues.apache.org/jira/browse/HBASE-21201
> Project: HBase
> Issue Type: Improvement
> Components: hbase-operator-tools
>Affects Versions: 3.0.0, 2.2.0
>Reporter: Sujit P
>Assignee: Toshihiro Suzuki
>Priority: Major
> Attachments: HBASE-21201.master.001.patch
>
>
> In some use cases, hbase clients writes to separate clusters(probably
> different datacenters) tables for redundancy. As an administrator/application
> architect, I would like to find out if both cluster tables are in the same
> state (cell by cell). One of the tools that is readily available to use is
> VerifyRep which is part of replication.
> However, it requires peerId to be setup on atleast of the involved cluster.
> PeerId is unnecessary in this use-case scenario and possibly cause unintended
> consequences as the clusters aren't really replication peers neither do We
> prefer them to be.
> Looking at the code:
> Tool attempts to get only the clusterKey which is essentially ZooKeeper
> quorum url
>
> {code:java}
> //VerifyReplication.java
> private static Pair
> getPeerQuorumConfig(final Configuration conf, String peerId)
> .
> .
> return Pair.newPair(peerConfig,
> ReplicationUtils.getPeerClusterConfiguration(peerConfig, conf));
> //ReplicationUtils.java
> public static Configuration getPeerClusterConfiguration(ReplicationPeerConfig
> peerConfig, Configuration baseConf) throws ReplicationException {
> Configuration otherConf;
> try {
> otherConf = HBaseConfiguration.createClusterConf(baseConf,
> peerConfig.getClusterKey());{code}
>
>
> So I would like to propose to update the tool to pass the remote cluster
> ZkQuorum as an argument (ex. --peerQuorumAddress
> clusterBzk1,clusterBzk2,clusterBzk3:2181/hbase-secure ) and use it
> effectively without dependence on replication peerId, similar to
> peerFSAddress. The are certain advantages in doing so as follows:
> * Reduce the development/maintenance of separate tool for above scenario
> * Allow the tool to be more useful for other scenarios as well such as
> ** validating backups in remote cluster HBASE-19106
> ** compare cloned tableA and original tableA in same/remote cluster incase
> of user error before restoring snapshot to original table to find the records
> that need to be added/invalid/missing etc
> ** Allow backup operators who are non-Hbase admins(who shouldn't be adding
> the peerId) to run the tool, since currently only Hbase superuser can add a
> peerId for reasons discussed in HBASE-21163.
> Please post your comments
> Thanks
> cc: [~clayb], [~brfrn169] , [~vrodionov] , [~rashidaligee]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21744) timeout for server list refresh calls
[ https://issues.apache.org/jira/browse/HBASE-21744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751719#comment-16751719 ] Sergey Shelukhin commented on HBASE-21744: -- Updated the patch to base refresh on timeout and heartbeat configs. Looks like none of this code is covered by unit tests, RefreshRunnable is relatively easy to test in isolation with some refactoring, I may add a test later. > timeout for server list refresh calls > -- > > Key: HBASE-21744 > URL: https://issues.apache.org/jira/browse/HBASE-21744 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-21744.01.patch, HBASE-21744.patch > > > Not sure why yet, but we are seeing the case when cluster is in overall a bad > state, where after RS dies and deletes its znode, the notification looks like > it's lost, so the master doesn't detect the failure. ZK itself appears to be > healthy and doesn't report anything special. > After some other change is made to the server list, master rescans the list > and picks up the stale change. Might make sense to add a config that would > trigger the refresh if it hasn't happened for a while (e.g. 1 minute). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21775) The BufferedMutator doesn't ever refresh region location cache
[
https://issues.apache.org/jira/browse/HBASE-21775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommy Li updated HBASE-21775:
-
Description:
{color:#22}I noticed in some of my writing jobs that the BufferedMutator
would get stuck retrying writes against a dead server.{color}
{code:java}
19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:15:54 WARN [htable-pool3-t56] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=15/21, failureCount=1ops, last
exception=org.apache.hadoop.hbase.DoNotRetryIOException: Operation rpcTimeout
on ,17020,1547848193782, tracking started Fri Jan 18 14:55:37 PST 2019;
NOT retrying, failed=1 -- final attempt!
19/01/18 15:15:54 ERROR [Executor task launch worker for task 0]
IngestRawData.map(): [B@258bc2c7:
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
action: Operation rpcTimeout: 1 time, servers with issues:
,17020,1547848193782
{code}
After the single remaining action permanently failed, it would resume progress
only to get stuck again retrying against the same dead server:
{code:java}
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:20 INFO [htable-pool3-t55] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=6/21, failureCount=1ops, last
exception=java.net.ConnectException: Call to failed on connection
exception:
org.apache.hbase.thirdparty.io.netty.channel.ConnectTimeoutException:
connection timed out: on ,17020,1547848193782, tracking
started null, retrying after=20089ms, operationsToReplay=1
{code}
Only restarting the client process to generate a new BufferedMutator instance
would fix the issue, at least until the next regionserver crash
The logs I've pasted show the issue happening with a
ConnectionTimeoutException, but we've also seen it with
NotServingRegionException and some others
was:
{color:#22}I noticed in some of my writing jobs that the BufferedMutator
would get stuck retrying writes against a dead server.{color}
{code:java}
19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:15:54 WARN [htable-pool3-t56] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=15/21, failureCount=1ops, last
exception=org.apache.hadoop.hbase.DoNotRetryIOException: Operation rpcTimeout
on ,17020,1547848193782, tracking started Fri Jan 18 14:55:37 PST 2019;
NOT retrying, failed=1 -- final attempt!
19/01/18 15:15:54 ERROR [Executor task launch worker for task 0]
IngestRawData.map(): [B@258bc2c7:
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
action: Operation rpcTimeout: 1 time, servers with issues:
,17020,1547848193782
{code}
After the single remaining action permanently failed, it would resume progress
only to get stuck again retrying against the same dead server:
{code:java}
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:20 INFO [htable-pool3-t55] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=6/21, failureCount=1ops, last
exception=java.net.ConnectException: Call to failed on connection
exception:
org.apache.hbase.thirdparty.io.netty.channel.ConnectTimeoutException:
connection timed out: on ,17020,1547848193782, tracking
started null, retrying after=20089ms, operationsToReplay=1
{code}
Only restarting the client process to generate a new BufferedMutator instance
would fix the issue, at least until the next regionserver crash
> The BufferedMutator doesn't ever refresh region location cache
> --
>
> Key: HBASE-21775
> URL: https://issues.apache.org/jira/browse/HBASE-21775
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Tommy Li
>Assignee: Tommy Li
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21775.master.001.patch
>
>
> {color:#22}I noticed in some of my writing jobs that the BufferedMutator
> would get stuck retrying writes against a dead server.{color}
> {code:java}
> 19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
> client.AsyncRequ
[jira] [Updated] (HBASE-21775) The BufferedMutator doesn't ever refresh region location cache
[
https://issues.apache.org/jira/browse/HBASE-21775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommy Li updated HBASE-21775:
-
Attachment: HBASE-21775.master.001.patch
> The BufferedMutator doesn't ever refresh region location cache
> --
>
> Key: HBASE-21775
> URL: https://issues.apache.org/jira/browse/HBASE-21775
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Tommy Li
>Assignee: Tommy Li
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21775.master.001.patch
>
>
> {color:#22}I noticed in some of my writing jobs that the BufferedMutator
> would get stuck retrying writes against a dead server.{color}
> {code:java}
> 19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:15:54 WARN [htable-pool3-t56] client.AsyncRequestFutureImpl:
> id=2, table=dummy_table, attempt=15/21, failureCount=1ops, last
> exception=org.apache.hadoop.hbase.DoNotRetryIOException: Operation rpcTimeout
> on ,17020,1547848193782, tracking started Fri Jan 18 14:55:37 PST
> 2019; NOT retrying, failed=1 -- final attempt!
> 19/01/18 15:15:54 ERROR [Executor task launch worker for task 0]
> IngestRawData.map(): [B@258bc2c7:
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: Operation rpcTimeout: 1 time, servers with issues:
> ,17020,1547848193782
> {code}
>
> After the single remaining action permanently failed, it would resume
> progress only to get stuck again retrying against the same dead server:
> {code:java}
> 19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:21:20 INFO [htable-pool3-t55] client.AsyncRequestFutureImpl:
> id=2, table=dummy_table, attempt=6/21, failureCount=1ops, last
> exception=java.net.ConnectException: Call to failed on connection
> exception:
> org.apache.hbase.thirdparty.io.netty.channel.ConnectTimeoutException:
> connection timed out: on ,17020,1547848193782, tracking
> started null, retrying after=20089ms, operationsToReplay=1
> {code}
>
> Only restarting the client process to generate a new BufferedMutator instance
> would fix the issue, at least until the next regionserver crash
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21775) The BufferedMutator doesn't ever refresh region location cache
[
https://issues.apache.org/jira/browse/HBASE-21775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommy Li updated HBASE-21775:
-
Status: Patch Available (was: Open)
> The BufferedMutator doesn't ever refresh region location cache
> --
>
> Key: HBASE-21775
> URL: https://issues.apache.org/jira/browse/HBASE-21775
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Tommy Li
>Assignee: Tommy Li
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21775.master.001.patch
>
>
> {color:#22}I noticed in some of my writing jobs that the BufferedMutator
> would get stuck retrying writes against a dead server.{color}
> {code:java}
> 19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:15:54 WARN [htable-pool3-t56] client.AsyncRequestFutureImpl:
> id=2, table=dummy_table, attempt=15/21, failureCount=1ops, last
> exception=org.apache.hadoop.hbase.DoNotRetryIOException: Operation rpcTimeout
> on ,17020,1547848193782, tracking started Fri Jan 18 14:55:37 PST
> 2019; NOT retrying, failed=1 -- final attempt!
> 19/01/18 15:15:54 ERROR [Executor task launch worker for task 0]
> IngestRawData.map(): [B@258bc2c7:
> org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
> action: Operation rpcTimeout: 1 time, servers with issues:
> ,17020,1547848193782
> {code}
>
> After the single remaining action permanently failed, it would resume
> progress only to get stuck again retrying against the same dead server:
> {code:java}
> 19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
> client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
> dummy_table
> 19/01/18 15:21:20 INFO [htable-pool3-t55] client.AsyncRequestFutureImpl:
> id=2, table=dummy_table, attempt=6/21, failureCount=1ops, last
> exception=java.net.ConnectException: Call to failed on connection
> exception:
> org.apache.hbase.thirdparty.io.netty.channel.ConnectTimeoutException:
> connection timed out: on ,17020,1547848193782, tracking
> started null, retrying after=20089ms, operationsToReplay=1
> {code}
>
> Only restarting the client process to generate a new BufferedMutator instance
> would fix the issue, at least until the next regionserver crash
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21775) The BufferedMutator doesn't ever refresh region location cache
Tommy Li created HBASE-21775:
Summary: The BufferedMutator doesn't ever refresh region location
cache
Key: HBASE-21775
URL: https://issues.apache.org/jira/browse/HBASE-21775
Project: HBase
Issue Type: Bug
Components: Client
Reporter: Tommy Li
Assignee: Tommy Li
Fix For: 3.0.0
{color:#22}I noticed in some of my writing jobs that the BufferedMutator
would get stuck retrying writes against a dead server.{color}
{code:java}
19/01/18 15:15:47 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:15:54 WARN [htable-pool3-t56] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=15/21, failureCount=1ops, last
exception=org.apache.hadoop.hbase.DoNotRetryIOException: Operation rpcTimeout
on ,17020,1547848193782, tracking started Fri Jan 18 14:55:37 PST 2019;
NOT retrying, failed=1 -- final attempt!
19/01/18 15:15:54 ERROR [Executor task launch worker for task 0]
IngestRawData.map(): [B@258bc2c7:
org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 1
action: Operation rpcTimeout: 1 time, servers with issues:
,17020,1547848193782
{code}
After the single remaining action permanently failed, it would resume progress
only to get stuck again retrying against the same dead server:
{code:java}
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:18 INFO [Executor task launch worker for task 0]
client.AsyncRequestFutureImpl: #2, waiting for 1 actions to finish on table:
dummy_table
19/01/18 15:21:20 INFO [htable-pool3-t55] client.AsyncRequestFutureImpl: id=2,
table=dummy_table, attempt=6/21, failureCount=1ops, last
exception=java.net.ConnectException: Call to failed on connection
exception:
org.apache.hbase.thirdparty.io.netty.channel.ConnectTimeoutException:
connection timed out: on ,17020,1547848193782, tracking
started null, retrying after=20089ms, operationsToReplay=1
{code}
Only restarting the client process to generate a new BufferedMutator instance
would fix the issue, at least until the next regionserver crash
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21774) do not use currentTimeMillis to measure intervals
[ https://issues.apache.org/jira/browse/HBASE-21774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21774: - Priority: Minor (was: Major) > do not use currentTimeMillis to measure intervals > - > > Key: HBASE-21774 > URL: https://issues.apache.org/jira/browse/HBASE-21774 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Priority: Minor > > I've noticed it in a few places in the code... > currentMillis can go backwards and have other artifacts. > nanoTime should be used for intervals (see > [https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()|https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()] > ) unless it's both the case that the calls are frequent and nanoTime will > result in perf overhead, and also that artifacts from negative intervals and > such are relatively harmless or possible to work around in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21774) do not use currentTimeMillis to measure intervals
[ https://issues.apache.org/jira/browse/HBASE-21774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21774: - Summary: do not use currentTimeMillis to measure intervals (was: do not use currentMillis to measure intervals) > do not use currentTimeMillis to measure intervals > - > > Key: HBASE-21774 > URL: https://issues.apache.org/jira/browse/HBASE-21774 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Priority: Major > > I've noticed it in a few places in the code... > currentMillis can go backwards and have other artifacts. > nanoTime should be used for intervals (see > [https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()|https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()] > ) unless it's both the case that the calls are frequent and nanoTime will > result in perf overhead, and also that artifacts from negative intervals and > such are relatively harmless or possible to work around in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21774) do not use currentMillis to measure intervals
[ https://issues.apache.org/jira/browse/HBASE-21774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21774: - Description: I've noticed it in a few places in the code... currentMillis can go backwards and have other artifacts. nanoTime should be used for intervals (see [https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()|https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()] ) unless it's both the case that the calls are frequent and nanoTime will result in perf overhead, and also that artifacts from negative intervals and such are relatively harmless or possible to work around in the code. was: I've noticed it in a few places in the code... currentMillis can go backwards and have other artifacts. nanoTime should be used for intervals (see https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime() ) unless it's both the case that the calls are frequent and nanoTime will result in perf overhead, and also that artifacts from negative intervals and such are relatively harmless or possible to work around in the code. > do not use currentMillis to measure intervals > - > > Key: HBASE-21774 > URL: https://issues.apache.org/jira/browse/HBASE-21774 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Priority: Major > > I've noticed it in a few places in the code... > currentMillis can go backwards and have other artifacts. > nanoTime should be used for intervals (see > [https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()|https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()] > ) unless it's both the case that the calls are frequent and nanoTime will > result in perf overhead, and also that artifacts from negative intervals and > such are relatively harmless or possible to work around in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21774) do not use currentMillis to measure intervals
[ https://issues.apache.org/jira/browse/HBASE-21774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21774: - Description: I've noticed it in a few places in the code... currentMillis can go backwards and have other artifacts. nanoTime should be used for intervals (see https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime() ) unless it's both the case that the calls are frequent and nanoTime will result in perf overhead, and also that artifacts from negative intervals and such are relatively harmless or possible to work around in the code. was: I've noticed it in a few places in the code... currentMillis can go backwards and have other artifacts. nanoTime should be used for intervals unless it's both the case that the calls are frequent and nanoTime will result in perf overhead, and also that artifacts from negative intervals and such are relatively harmless or possible to work around in the code. > do not use currentMillis to measure intervals > - > > Key: HBASE-21774 > URL: https://issues.apache.org/jira/browse/HBASE-21774 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Priority: Major > > I've noticed it in a few places in the code... > currentMillis can go backwards and have other artifacts. > nanoTime should be used for intervals (see > https://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime() ) > unless it's both the case that the calls are frequent and nanoTime will > result in perf overhead, and also that artifacts from negative intervals and > such are relatively harmless or possible to work around in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21774) do not use currentMillis to measure intervals
Sergey Shelukhin created HBASE-21774: Summary: do not use currentMillis to measure intervals Key: HBASE-21774 URL: https://issues.apache.org/jira/browse/HBASE-21774 Project: HBase Issue Type: Bug Reporter: Sergey Shelukhin I've noticed it in a few places in the code... currentMillis can go backwards and have other artifacts. nanoTime should be used for intervals unless it's both the case that the calls are frequent and nanoTime will result in perf overhead, and also that artifacts from negative intervals and such are relatively harmless or possible to work around in the code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21564) race condition in WAL rolling resulting in size-based rolling getting stuck
[ https://issues.apache.org/jira/browse/HBASE-21564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21564: - Attachment: HBASE-21564.06.patch > race condition in WAL rolling resulting in size-based rolling getting stuck > --- > > Key: HBASE-21564 > URL: https://issues.apache.org/jira/browse/HBASE-21564 > Project: HBase > Issue Type: Bug > Components: asyncclient, wal >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Attachments: HBASE-21564.06.patch, HBASE-21564.master.001.patch, > HBASE-21564.master.002.patch, HBASE-21564.master.003.patch, > HBASE-21564.master.004.patch, HBASE-21564.master.005.patch > > > Manifests at least with AsyncFsWriter. > There's a window after LogRoller replaces the writer in the WAL, but before > it sets the rollLog boolean to false in the finally, where the WAL class can > request another log roll (it can happen in particular when the logs are > getting archived in the LogRoller thread, and there's high write volume > causing the logs to roll quickly). > LogRoller will blindly reset the rollLog flag in finally and "forget" about > this request. > AsyncWAL in turn never requests it again because its own rollRequested field > is set and it expects a callback. Logs don't get rolled until a periodic roll > is triggered after that. > The acknowledgment of roll requests by LogRoller should be atomic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21564) race condition in WAL rolling resulting in size-based rolling getting stuck
[ https://issues.apache.org/jira/browse/HBASE-21564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21564: - Attachment: (was: HBASE-21564.06.patch) > race condition in WAL rolling resulting in size-based rolling getting stuck > --- > > Key: HBASE-21564 > URL: https://issues.apache.org/jira/browse/HBASE-21564 > Project: HBase > Issue Type: Bug > Components: asyncclient, wal >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Attachments: HBASE-21564.06.patch, HBASE-21564.master.001.patch, > HBASE-21564.master.002.patch, HBASE-21564.master.003.patch, > HBASE-21564.master.004.patch, HBASE-21564.master.005.patch > > > Manifests at least with AsyncFsWriter. > There's a window after LogRoller replaces the writer in the WAL, but before > it sets the rollLog boolean to false in the finally, where the WAL class can > request another log roll (it can happen in particular when the logs are > getting archived in the LogRoller thread, and there's high write volume > causing the logs to roll quickly). > LogRoller will blindly reset the rollLog flag in finally and "forget" about > this request. > AsyncWAL in turn never requests it again because its own rollRequested field > is set and it expects a callback. Logs don't get rolled until a periodic roll > is triggered after that. > The acknowledgment of roll requests by LogRoller should be atomic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21564) race condition in WAL rolling resulting in size-based rolling getting stuck
[ https://issues.apache.org/jira/browse/HBASE-21564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-21564: - Attachment: HBASE-21564.06.patch > race condition in WAL rolling resulting in size-based rolling getting stuck > --- > > Key: HBASE-21564 > URL: https://issues.apache.org/jira/browse/HBASE-21564 > Project: HBase > Issue Type: Bug > Components: asyncclient, wal >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Attachments: HBASE-21564.06.patch, HBASE-21564.master.001.patch, > HBASE-21564.master.002.patch, HBASE-21564.master.003.patch, > HBASE-21564.master.004.patch, HBASE-21564.master.005.patch > > > Manifests at least with AsyncFsWriter. > There's a window after LogRoller replaces the writer in the WAL, but before > it sets the rollLog boolean to false in the finally, where the WAL class can > request another log roll (it can happen in particular when the logs are > getting archived in the LogRoller thread, and there's high write volume > causing the logs to roll quickly). > LogRoller will blindly reset the rollLog flag in finally and "forget" about > this request. > AsyncWAL in turn never requests it again because its own rollRequested field > is set and it expects a callback. Logs don't get rolled until a periodic roll > is triggered after that. > The acknowledgment of roll requests by LogRoller should be atomic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20662) Increasing space quota on a violated table does not remove SpaceViolationPolicy.DISABLE enforcement
[
https://issues.apache.org/jira/browse/HBASE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751604#comment-16751604
]
Hadoop QA commented on HBASE-20662:
---
| (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:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-20662 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.8.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-20662 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956198/HBASE-20662.master.008.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15724/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Increasing space quota on a violated table does not remove
> SpaceViolationPolicy.DISABLE enforcement
> ---
>
> Key: HBASE-20662
> URL: https://issues.apache.org/jira/browse/HBASE-20662
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20662.master.001.patch,
> HBASE-20662.master.002.patch, HBASE-20662.master.003.patch,
> HBASE-20662.master.004.patch, HBASE-20662.master.004.patch,
> HBASE-20662.master.005.patch, HBASE-20662.master.006.patch,
> HBASE-20662.master.007.patch, HBASE-20662.master.008.patch
>
>
> *Steps to reproduce*
> * Create a table and set quota with {{SpaceViolationPolicy.DISABLE}} having
> limit say 2MB
> * Now put rows until space quota is violated and table gets disabled
> * Next, increase space quota with limit say 4MB on the table
> * Now try putting a row into the table
> {code:java}
> private void testSetQuotaThenViolateAndFinallyIncreaseQuota() throws
> Exception {
> SpaceViolationPolicy policy = SpaceViolationPolicy.DISABLE;
> Put put = new Put(Bytes.toBytes("to_reject"));
> put.addColumn(Bytes.toBytes(SpaceQuotaHelperForTests.F1),
> Bytes.toBytes("to"),
> Bytes.toBytes("reject"));
> // Do puts until we violate space policy
> final TableName tn = writeUntilViolationAndVerifyViolation(policy, put);
> // Now, increase limit
> setQuotaLimit(tn, policy, 4L);
> // Put some row now: should not violate as quota limit increased
> verifyNoViolation(policy, tn, put);
> }
> {code}
> *Expected*
> We should be able to put data as long as newly set quota limit is not reached
> *Actual*
> We fail to put any new row even after increasing limit
> *Root cause*
> Increasing quota on a violated table triggers the table to be enabled, but
> since the table is already in violation, the system does not allow it to be
> enabled (may be thinking that a user is trying to enable it)
> *Relevant exception trace*
> {noformat}
> 2018-05-31 00:34:27,563 INFO [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> client.HBaseAdmin$14(844): Started enable of
> testSetQuotaAndThenIncreaseQuotaWithDisable0
> 2018-05-31 00:34:27,571 DEBUG
> [RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=42525]
> ipc.CallRunner(142): callId: 11 service: MasterService methodName:
> EnableTable size: 104 connection: 127.0.0.1:38030 deadline: 1527707127568,
> exception=org.apache.hadoop.hbase.security.AccessDeniedException: Enabling
> the table 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to
> a violated space quota.
> 2018-05-31 00:34:27,571 ERROR [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> quotas.RegionServerSpaceQuotaManager(210): Failed to disable space violation
> policy for testSetQuotaAndThenIncreaseQuotaWithDisable0. This table will
> remain in violation.
> org.apache.hadoop.hbase.security.AccessDeniedException:
> org.apache.hadoop.hbase.security.AccessDeniedException: Enabling the table
> 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to a
> violated space quota.
> at org.apache.hadoop.hbase.master.HMaster$6.run(HMaster.java:2275)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:131)
> at org.apache.hadoop.hbase.master.HMaster.enableTable(HMaster.java:2258)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.enableTable(MasterRpcServices.java:725)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlocking
[jira] [Commented] (HBASE-21638) Remove dead links from hbase.apache.org
[
https://issues.apache.org/jira/browse/HBASE-21638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751581#comment-16751581
]
Sakthi commented on HBASE-21638:
Of the reported 1458 missing files, almost all of them are javadoc issues(1200
of them belonging to 1.2 itself, around 90 of them from 0.94, 40 from 2.0, 30
from 2.1 & rest master).
> Remove dead links from hbase.apache.org
> ---
>
> Key: HBASE-21638
> URL: https://issues.apache.org/jira/browse/HBASE-21638
> Project: HBase
> Issue Type: Sub-task
> Components: website
>Reporter: Peter Somogyi
>Assignee: Sakthi
>Priority: Minor
>
> The HBase Website Link Checker report contains many dead links. Fix these:
> {noformat}
> Index of Linklint results
> Sat, 22-Dec-2018 05:03:16 (local)
> Linklint version: 2.3.5_ingo_020
> summary.txt: summary of results
> log.txt: log of progress
> file.html: found 51118 files
>fileX.html: found 51118 files (cross referenced)
>fileF.html: found 50982 files with forward links
> remote.html: found 3414 other links
> remoteX.html: found 3414 other links (cross referenced)
> anchor.html: found 21516049 named anchors
> anchorX.html: found 21516049 named anchors (cross referenced)
> action.html: - 1 action skipped
> actionX.html: - 1 action skipped (cross referenced)
> skipped.html: - 2 files skipped
>skipX.html: - 2 files skipped (cross referenced)
> warn.html: warn 696 warnings
>warnX.html: warn 696 warnings (cross referenced)
>warnF.html: warn 253 files with warnings
>error.html: ERROR 1458 missing files
> errorX.html: ERROR 1458 missing files (cross referenced)
> errorF.html: ERROR 1417 files had broken links
> errorA.html: ERROR 7143 missing named anchors
> errorAX.html: ERROR 7143 missing named anchors (cross referenced)
> httpfail.html: - 1458 links: failed via http
> httpok.html: - 51118 links: ok via http
> mapped.html: - 4 links were mapped
> urlindex.html: results for remote urls
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21728) Backport to branch-2 (and maybe branch-1) HBASE-21684 Throw DNRIOE when connection or rpc client is closed
[ https://issues.apache.org/jira/browse/HBASE-21728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751568#comment-16751568 ] Sergey Shelukhin commented on HBASE-21728: -- Should this be resolved? > Backport to branch-2 (and maybe branch-1) HBASE-21684 Throw DNRIOE when > connection or rpc client is closed > -- > > Key: HBASE-21728 > URL: https://issues.apache.org/jira/browse/HBASE-21728 > Project: HBase > Issue Type: Sub-task >Reporter: stack >Priority: Major > Fix For: 1.5.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21728-branch-1.001.patch > > > Backport the parent. May need a few changes. See suggestions in parent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-21773) rowcounter utility should respond to pleas for help
[
https://issues.apache.org/jira/browse/HBASE-21773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wellington Chevreuil reassigned HBASE-21773:
Assignee: Wellington Chevreuil
> rowcounter utility should respond to pleas for help
> ---
>
> Key: HBASE-21773
> URL: https://issues.apache.org/jira/browse/HBASE-21773
> Project: HBase
> Issue Type: Bug
> Components: tooling
>Affects Versions: 2.1.0
>Reporter: Sean Busbey
>Assignee: Wellington Chevreuil
>Priority: Critical
>
> {{hbase rowcounter}} does not respond to reasonable requests for help, i.e.
> {{--help}}, {{-h}}, or {{-?}}
> {code}
> [systest@busbey-training-1 root]$ hbase rowcounter -?
> OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and
> will likely be removed in a future release
> 19/01/24 12:30:00 INFO client.RMProxy: Connecting to ResourceManager at
> busbey-training-1.gce.cloudera.com/172.31.116.31:8032
> 19/01/24 12:30:01 INFO hdfs.DFSClient: Created token for systest:
> HDFS_DELEGATION_TOKEN owner=syst...@gce.cloudera.com, renewer=yarn,
> realUser=, issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3,
> masterKeyId=8 on 172.31.116.31:8020
> 19/01/24 12:30:01 INFO kms.KMSClientProvider: Getting new token from
> https://busbey-training-3.gce.cloudera.com:16000/kms/v1/,
> renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
> kms-dt, Service: 172.31.116.52:16000, Ident: (kms-dt owner=systest,
> renewer=yarn, realUser=, issueDate=1548361801965, maxDate=1548966601965,
> sequenceNumber=5, masterKeyId=17))
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: HDFS_DELEGATION_TOKEN,
> Service: 172.31.116.31:8020, Ident: (token for systest: HDFS_DELEGATION_TOKEN
> owner=syst...@gce.cloudera.com, renewer=yarn, realUser=,
> issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3,
> masterKeyId=8)
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
> 172.31.116.52:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
> issueDate=1548361801965, maxDate=1548966601965, sequenceNumber=5,
> masterKeyId=17)
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: Getting new token from
> https://busbey-training-4.gce.cloudera.com:16000/kms/v1/,
> renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
> kms-dt, Service: 172.31.116.50:16000, Ident: (kms-dt owner=systest,
> renewer=yarn, realUser=, issueDate=1548361802363, maxDate=1548966602363,
> sequenceNumber=6, masterKeyId=18))
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
> 172.31.116.50:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
> issueDate=1548361802363, maxDate=1548966602363, sequenceNumber=6,
> masterKeyId=18)
> 19/01/24 12:30:02 INFO mapreduce.JobResourceUploader: Disabling Erasure
> Coding for path: /user/systest/.staging/job_1548349234632_0003
> 19/01/24 12:30:03 INFO mapreduce.JobSubmitter: Cleaning up the staging area
> /user/systest/.staging/job_1548349234632_0003
> Exception in thread "main" java.lang.IllegalArgumentException: Illegal first
> character <45> at 0. User-space table qualifiers can only start with
> 'alphanumeric characters' from any language: -?
> at
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:193)
> at
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:156)
> at org.apache.hadoop.hbase.TableName.(TableName.java:346)
> at
> org.apache.hadoop.hbase.TableName.createTableNameIfNecessary(TableName.java:382)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:469)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormat.initialize(TableInputFormat.java:198)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.getSplits(TableInputFormatBase.java:243)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormat.getSplits(TableInputFormat.java:254)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:310)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:327)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:200)
> at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1570)
> at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1567)
> at java.security.AccessController.doPrivileged(Native Method)
> at j
[jira] [Created] (HBASE-21773) rowcounter utility should respond to please for help
Sean Busbey created HBASE-21773:
---
Summary: rowcounter utility should respond to please for help
Key: HBASE-21773
URL: https://issues.apache.org/jira/browse/HBASE-21773
Project: HBase
Issue Type: Bug
Components: tooling
Affects Versions: 2.1.0
Reporter: Sean Busbey
{{hbase rowcounter}} does not respond to reasonable requests for help, i.e.
{{--help}}, {{-h}}, or {{-?}}
{code}
[systest@busbey-training-1 root]$ hbase rowcounter -?
OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and will
likely be removed in a future release
19/01/24 12:30:00 INFO client.RMProxy: Connecting to ResourceManager at
busbey-training-1.gce.cloudera.com/172.31.116.31:8032
19/01/24 12:30:01 INFO hdfs.DFSClient: Created token for systest:
HDFS_DELEGATION_TOKEN owner=syst...@gce.cloudera.com, renewer=yarn, realUser=,
issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3, masterKeyId=8
on 172.31.116.31:8020
19/01/24 12:30:01 INFO kms.KMSClientProvider: Getting new token from
https://busbey-training-3.gce.cloudera.com:16000/kms/v1/,
renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
kms-dt, Service: 172.31.116.52:16000, Ident: (kms-dt owner=systest,
renewer=yarn, realUser=, issueDate=1548361801965, maxDate=1548966601965,
sequenceNumber=5, masterKeyId=17))
19/01/24 12:30:02 INFO security.TokenCache: Got dt for
hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: HDFS_DELEGATION_TOKEN,
Service: 172.31.116.31:8020, Ident: (token for systest: HDFS_DELEGATION_TOKEN
owner=syst...@gce.cloudera.com, renewer=yarn, realUser=,
issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3, masterKeyId=8)
19/01/24 12:30:02 INFO security.TokenCache: Got dt for
hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
172.31.116.52:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
issueDate=1548361801965, maxDate=1548966601965, sequenceNumber=5,
masterKeyId=17)
19/01/24 12:30:02 INFO kms.KMSClientProvider: Getting new token from
https://busbey-training-4.gce.cloudera.com:16000/kms/v1/,
renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
kms-dt, Service: 172.31.116.50:16000, Ident: (kms-dt owner=systest,
renewer=yarn, realUser=, issueDate=1548361802363, maxDate=1548966602363,
sequenceNumber=6, masterKeyId=18))
19/01/24 12:30:02 INFO security.TokenCache: Got dt for
hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
172.31.116.50:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
issueDate=1548361802363, maxDate=1548966602363, sequenceNumber=6,
masterKeyId=18)
19/01/24 12:30:02 INFO mapreduce.JobResourceUploader: Disabling Erasure Coding
for path: /user/systest/.staging/job_1548349234632_0003
19/01/24 12:30:03 INFO mapreduce.JobSubmitter: Cleaning up the staging area
/user/systest/.staging/job_1548349234632_0003
Exception in thread "main" java.lang.IllegalArgumentException: Illegal first
character <45> at 0. User-space table qualifiers can only start with
'alphanumeric characters' from any language: -?
at
org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:193)
at
org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:156)
at org.apache.hadoop.hbase.TableName.(TableName.java:346)
at
org.apache.hadoop.hbase.TableName.createTableNameIfNecessary(TableName.java:382)
at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:469)
at
org.apache.hadoop.hbase.mapreduce.TableInputFormat.initialize(TableInputFormat.java:198)
at
org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.getSplits(TableInputFormatBase.java:243)
at
org.apache.hadoop.hbase.mapreduce.TableInputFormat.getSplits(TableInputFormat.java:254)
at
org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:310)
at
org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:327)
at
org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:200)
at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1570)
at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1567)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1875)
at org.apache.hadoop.mapreduce.Job.submit(Job.java:1567)
at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1588)
at org.apache.hadoop.hbase.mapreduce.RowCounter.run(RowCounter.java:242)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76)
at
o
[jira] [Updated] (HBASE-21773) rowcounter utility should respond to pleas for help
[
https://issues.apache.org/jira/browse/HBASE-21773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-21773:
Summary: rowcounter utility should respond to pleas for help (was:
rowcounter utility should respond to please for help)
> rowcounter utility should respond to pleas for help
> ---
>
> Key: HBASE-21773
> URL: https://issues.apache.org/jira/browse/HBASE-21773
> Project: HBase
> Issue Type: Bug
> Components: tooling
>Affects Versions: 2.1.0
>Reporter: Sean Busbey
>Priority: Critical
>
> {{hbase rowcounter}} does not respond to reasonable requests for help, i.e.
> {{--help}}, {{-h}}, or {{-?}}
> {code}
> [systest@busbey-training-1 root]$ hbase rowcounter -?
> OpenJDK 64-Bit Server VM warning: Using incremental CMS is deprecated and
> will likely be removed in a future release
> 19/01/24 12:30:00 INFO client.RMProxy: Connecting to ResourceManager at
> busbey-training-1.gce.cloudera.com/172.31.116.31:8032
> 19/01/24 12:30:01 INFO hdfs.DFSClient: Created token for systest:
> HDFS_DELEGATION_TOKEN owner=syst...@gce.cloudera.com, renewer=yarn,
> realUser=, issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3,
> masterKeyId=8 on 172.31.116.31:8020
> 19/01/24 12:30:01 INFO kms.KMSClientProvider: Getting new token from
> https://busbey-training-3.gce.cloudera.com:16000/kms/v1/,
> renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
> kms-dt, Service: 172.31.116.52:16000, Ident: (kms-dt owner=systest,
> renewer=yarn, realUser=, issueDate=1548361801965, maxDate=1548966601965,
> sequenceNumber=5, masterKeyId=17))
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: HDFS_DELEGATION_TOKEN,
> Service: 172.31.116.31:8020, Ident: (token for systest: HDFS_DELEGATION_TOKEN
> owner=syst...@gce.cloudera.com, renewer=yarn, realUser=,
> issueDate=1548361801519, maxDate=1548966601519, sequenceNumber=3,
> masterKeyId=8)
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
> 172.31.116.52:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
> issueDate=1548361801965, maxDate=1548966601965, sequenceNumber=5,
> masterKeyId=17)
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: Getting new token from
> https://busbey-training-4.gce.cloudera.com:16000/kms/v1/,
> renewer:yarn/busbey-training-1.gce.cloudera@gce.cloudera.com
> 19/01/24 12:30:02 INFO kms.KMSClientProvider: New token received: (Kind:
> kms-dt, Service: 172.31.116.50:16000, Ident: (kms-dt owner=systest,
> renewer=yarn, realUser=, issueDate=1548361802363, maxDate=1548966602363,
> sequenceNumber=6, masterKeyId=18))
> 19/01/24 12:30:02 INFO security.TokenCache: Got dt for
> hdfs://busbey-training-1.gce.cloudera.com:8020; Kind: kms-dt, Service:
> 172.31.116.50:16000, Ident: (kms-dt owner=systest, renewer=yarn, realUser=,
> issueDate=1548361802363, maxDate=1548966602363, sequenceNumber=6,
> masterKeyId=18)
> 19/01/24 12:30:02 INFO mapreduce.JobResourceUploader: Disabling Erasure
> Coding for path: /user/systest/.staging/job_1548349234632_0003
> 19/01/24 12:30:03 INFO mapreduce.JobSubmitter: Cleaning up the staging area
> /user/systest/.staging/job_1548349234632_0003
> Exception in thread "main" java.lang.IllegalArgumentException: Illegal first
> character <45> at 0. User-space table qualifiers can only start with
> 'alphanumeric characters' from any language: -?
> at
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:193)
> at
> org.apache.hadoop.hbase.TableName.isLegalTableQualifierName(TableName.java:156)
> at org.apache.hadoop.hbase.TableName.(TableName.java:346)
> at
> org.apache.hadoop.hbase.TableName.createTableNameIfNecessary(TableName.java:382)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:469)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormat.initialize(TableInputFormat.java:198)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormatBase.getSplits(TableInputFormatBase.java:243)
> at
> org.apache.hadoop.hbase.mapreduce.TableInputFormat.getSplits(TableInputFormat.java:254)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeNewSplits(JobSubmitter.java:310)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.writeSplits(JobSubmitter.java:327)
> at
> org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:200)
> at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1570)
> at org.apache.hadoop.mapreduce.Job$11.run(Job.java:1567)
> at java.security.AccessController.doPrivileged(Native
[jira] [Updated] (HBASE-20662) Increasing space quota on a violated table does not remove SpaceViolationPolicy.DISABLE enforcement
[
https://issues.apache.org/jira/browse/HBASE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nihal Jain updated HBASE-20662:
---
Attachment: HBASE-20662.master.008.patch
> Increasing space quota on a violated table does not remove
> SpaceViolationPolicy.DISABLE enforcement
> ---
>
> Key: HBASE-20662
> URL: https://issues.apache.org/jira/browse/HBASE-20662
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20662.master.001.patch,
> HBASE-20662.master.002.patch, HBASE-20662.master.003.patch,
> HBASE-20662.master.004.patch, HBASE-20662.master.004.patch,
> HBASE-20662.master.005.patch, HBASE-20662.master.006.patch,
> HBASE-20662.master.007.patch, HBASE-20662.master.008.patch
>
>
> *Steps to reproduce*
> * Create a table and set quota with {{SpaceViolationPolicy.DISABLE}} having
> limit say 2MB
> * Now put rows until space quota is violated and table gets disabled
> * Next, increase space quota with limit say 4MB on the table
> * Now try putting a row into the table
> {code:java}
> private void testSetQuotaThenViolateAndFinallyIncreaseQuota() throws
> Exception {
> SpaceViolationPolicy policy = SpaceViolationPolicy.DISABLE;
> Put put = new Put(Bytes.toBytes("to_reject"));
> put.addColumn(Bytes.toBytes(SpaceQuotaHelperForTests.F1),
> Bytes.toBytes("to"),
> Bytes.toBytes("reject"));
> // Do puts until we violate space policy
> final TableName tn = writeUntilViolationAndVerifyViolation(policy, put);
> // Now, increase limit
> setQuotaLimit(tn, policy, 4L);
> // Put some row now: should not violate as quota limit increased
> verifyNoViolation(policy, tn, put);
> }
> {code}
> *Expected*
> We should be able to put data as long as newly set quota limit is not reached
> *Actual*
> We fail to put any new row even after increasing limit
> *Root cause*
> Increasing quota on a violated table triggers the table to be enabled, but
> since the table is already in violation, the system does not allow it to be
> enabled (may be thinking that a user is trying to enable it)
> *Relevant exception trace*
> {noformat}
> 2018-05-31 00:34:27,563 INFO [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> client.HBaseAdmin$14(844): Started enable of
> testSetQuotaAndThenIncreaseQuotaWithDisable0
> 2018-05-31 00:34:27,571 DEBUG
> [RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=42525]
> ipc.CallRunner(142): callId: 11 service: MasterService methodName:
> EnableTable size: 104 connection: 127.0.0.1:38030 deadline: 1527707127568,
> exception=org.apache.hadoop.hbase.security.AccessDeniedException: Enabling
> the table 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to
> a violated space quota.
> 2018-05-31 00:34:27,571 ERROR [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> quotas.RegionServerSpaceQuotaManager(210): Failed to disable space violation
> policy for testSetQuotaAndThenIncreaseQuotaWithDisable0. This table will
> remain in violation.
> org.apache.hadoop.hbase.security.AccessDeniedException:
> org.apache.hadoop.hbase.security.AccessDeniedException: Enabling the table
> 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to a
> violated space quota.
> at org.apache.hadoop.hbase.master.HMaster$6.run(HMaster.java:2275)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:131)
> at org.apache.hadoop.hbase.master.HMaster.enableTable(HMaster.java:2258)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.enableTable(MasterRpcServices.java:725)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.instantiateException(RemoteWithExtrasException.java:100)
> at
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException.unwrapRemoteExce
[jira] [Commented] (HBASE-20662) Increasing space quota on a violated table does not remove SpaceViolationPolicy.DISABLE enforcement
[
https://issues.apache.org/jira/browse/HBASE-20662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751489#comment-16751489
]
Nihal Jain commented on HBASE-20662:
[^HBASE-20662.master.007.patch] does not apply now. Submitted
[^HBASE-20662.master.008.patch] and raised rb @
[https://reviews.apache.org/r/69833/.|https://reviews.apache.org/r/69833/]
Please review
> Increasing space quota on a violated table does not remove
> SpaceViolationPolicy.DISABLE enforcement
> ---
>
> Key: HBASE-20662
> URL: https://issues.apache.org/jira/browse/HBASE-20662
> Project: HBase
> Issue Type: Bug
>Affects Versions: 3.0.0, 2.0.0
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20662.master.001.patch,
> HBASE-20662.master.002.patch, HBASE-20662.master.003.patch,
> HBASE-20662.master.004.patch, HBASE-20662.master.004.patch,
> HBASE-20662.master.005.patch, HBASE-20662.master.006.patch,
> HBASE-20662.master.007.patch, HBASE-20662.master.008.patch
>
>
> *Steps to reproduce*
> * Create a table and set quota with {{SpaceViolationPolicy.DISABLE}} having
> limit say 2MB
> * Now put rows until space quota is violated and table gets disabled
> * Next, increase space quota with limit say 4MB on the table
> * Now try putting a row into the table
> {code:java}
> private void testSetQuotaThenViolateAndFinallyIncreaseQuota() throws
> Exception {
> SpaceViolationPolicy policy = SpaceViolationPolicy.DISABLE;
> Put put = new Put(Bytes.toBytes("to_reject"));
> put.addColumn(Bytes.toBytes(SpaceQuotaHelperForTests.F1),
> Bytes.toBytes("to"),
> Bytes.toBytes("reject"));
> // Do puts until we violate space policy
> final TableName tn = writeUntilViolationAndVerifyViolation(policy, put);
> // Now, increase limit
> setQuotaLimit(tn, policy, 4L);
> // Put some row now: should not violate as quota limit increased
> verifyNoViolation(policy, tn, put);
> }
> {code}
> *Expected*
> We should be able to put data as long as newly set quota limit is not reached
> *Actual*
> We fail to put any new row even after increasing limit
> *Root cause*
> Increasing quota on a violated table triggers the table to be enabled, but
> since the table is already in violation, the system does not allow it to be
> enabled (may be thinking that a user is trying to enable it)
> *Relevant exception trace*
> {noformat}
> 2018-05-31 00:34:27,563 INFO [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> client.HBaseAdmin$14(844): Started enable of
> testSetQuotaAndThenIncreaseQuotaWithDisable0
> 2018-05-31 00:34:27,571 DEBUG
> [RpcServer.default.FPBQ.Fifo.handler=3,queue=0,port=42525]
> ipc.CallRunner(142): callId: 11 service: MasterService methodName:
> EnableTable size: 104 connection: 127.0.0.1:38030 deadline: 1527707127568,
> exception=org.apache.hadoop.hbase.security.AccessDeniedException: Enabling
> the table 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to
> a violated space quota.
> 2018-05-31 00:34:27,571 ERROR [regionserver/root1-ThinkPad-T440p:0.Chore.1]
> quotas.RegionServerSpaceQuotaManager(210): Failed to disable space violation
> policy for testSetQuotaAndThenIncreaseQuotaWithDisable0. This table will
> remain in violation.
> org.apache.hadoop.hbase.security.AccessDeniedException:
> org.apache.hadoop.hbase.security.AccessDeniedException: Enabling the table
> 'testSetQuotaAndThenIncreaseQuotaWithDisable0' is disallowed due to a
> violated space quota.
> at org.apache.hadoop.hbase.master.HMaster$6.run(HMaster.java:2275)
> at
> org.apache.hadoop.hbase.master.procedure.MasterProcedureUtil.submitProcedure(MasterProcedureUtil.java:131)
> at org.apache.hadoop.hbase.master.HMaster.enableTable(HMaster.java:2258)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.enableTable(MasterRpcServices.java:725)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.j
[jira] [Commented] (HBASE-21636) Enhance the shell scan command to support missing scanner specifications like ReadType, IsolationLevel etc.
[
https://issues.apache.org/jira/browse/HBASE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751426#comment-16751426
]
Hadoop QA commented on HBASE-21636:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} @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
22s{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} 4m
10s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
14s{color} | {color:red} The patch generated 12 new + 413 unchanged - 8 fixed =
425 total (was 421) {color} |
| {color:orange}-0{color} | {color:orange} ruby-lint {color} | {color:orange}
0m 14s{color} | {color:orange} The patch generated 38 new + 622 unchanged - 0
fixed = 660 total (was 622) {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} 6m
49s{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} 16m 55s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21636 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956183/HBASE-21636.master.002.patch
|
| Optional Tests | dupname asflicense javac javadoc unit rubocop
ruby_lint |
| uname | Linux b9146ab30855 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 416b70f461 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| rubocop | v0.60.0 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/15723/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/15723/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/15723/testReport/ |
| Max. process+thread count | 2609 (vs. ulimit of 1) |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15723/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Enhance the shell scan command to support missing scanner specifications like
> ReadType, IsolationLevel etc.
> ---
>
> Key: HBASE-21636
> URL: https://issues.apache.org/jira/browse/HBASE-21636
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 3.0.0, 2.0.0, 2.1.2
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Attachments: HBASE-21636.master.001.patch,
> HBASE-21636.master.002.patch
>
>
> Enhance the shell scan command to support scanner specifications:
> - ReadType
> - IsolationLevel
> - Region replica id
> - Allow partial results
> - Batch
> - Max result size
> Also, make use of \{{limit}} and set it in the scan object to limit the
> number of rows returned by the scanner.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21636) Enhance the shell scan command to support missing scanner specifications like ReadType, IsolationLevel etc.
[
https://issues.apache.org/jira/browse/HBASE-21636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nihal Jain updated HBASE-21636:
---
Attachment: HBASE-21636.master.002.patch
> Enhance the shell scan command to support missing scanner specifications like
> ReadType, IsolationLevel etc.
> ---
>
> Key: HBASE-21636
> URL: https://issues.apache.org/jira/browse/HBASE-21636
> Project: HBase
> Issue Type: Improvement
> Components: shell
>Affects Versions: 3.0.0, 2.0.0, 2.1.2
>Reporter: Nihal Jain
>Assignee: Nihal Jain
>Priority: Major
> Attachments: HBASE-21636.master.001.patch,
> HBASE-21636.master.002.patch
>
>
> Enhance the shell scan command to support scanner specifications:
> - ReadType
> - IsolationLevel
> - Region replica id
> - Allow partial results
> - Batch
> - Max result size
> Also, make use of \{{limit}} and set it in the scan object to limit the
> number of rows returned by the scanner.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21667) Move to latest ASF Parent POM
[ https://issues.apache.org/jira/browse/HBASE-21667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751399#comment-16751399 ] Sean Busbey commented on HBASE-21667: - I usually consider things that would come in a parent pom upgrade (plugin versions etc) to be a low priority for branch-1.2. If it doesn't beak anything I'm fine with it. If something looks off or if the backport is a bunch of work, I wouldn't bother with it. AFAICT things are up to date enough for me to reliably make RCs through April (because I have machines with specific versions of JDK and mvn for creating them), so I don't think much about e.g. things working easily with newer maven versions. > Move to latest ASF Parent POM > - > > Key: HBASE-21667 > URL: https://issues.apache.org/jira/browse/HBASE-21667 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Minor > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-21667.branch-2.0.001.patch, > HBASE-21667.branch-2.0.002.patch, HBASE-21667.branch-2.001.patch, > HBASE-21667.master.001.patch, HBASE-21667.master.002.patch > > > Currently HBase depends on version 18 which was released on 2016-05-18. > Version 21 was released in August 2018. > Relevant dependency upgrades > > ||Name||Currently used version||New version||Notes|| > |surefire.version|2.21.0|2.22.0| | > |maven-compiler-plugin|3.6.1|3.7| | > |maven-dependency-plugin|3.0.1|3.1.1| | > |maven-jar-plugin|3.0.0|3.0.2| | > |maven-javadoc-plugin|3.0.0|3.0.1| | > |maven-resources-plugin|2.7|3.1.0| | > |maven-site-plugin|3.4|3.7.1|Currently not relying on ASF version. See: > HBASE-18333| > |maven-source-plugin|3.0.0|3.0.1| | > |maven-shade-plugin|3.0.0|3.1.1|Newly added to ASF pom| > |maven-clean-plugin|3.0.0|3.1.0| | > |maven-project-info-reports-plugin |2.9|3.0.0| | > Version 21 added net.nicoulaj.maven.plugins:checksum-maven-plugin which > introduced SHA512 checksum instead of SHA1. Should verify if we can rely on > that for releases or breaks our current processes. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21487) Concurrent modify table ops can lead to unexpected results
[
https://issues.apache.org/jira/browse/HBASE-21487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751361#comment-16751361
]
Hadoop QA commented on HBASE-21487:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
2s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
55s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 14m
44s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
51s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
55s{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
22s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
5s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 13m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 13m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 13m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
46s{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} 3m
41s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 21s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
0s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
31s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
14s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}125m 43s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
6s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}205m 48s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-21487 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956151/HBASE-21487.branch-2.03.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile cc
[jira] [Commented] (HBASE-21770) Should deal with meta table in HRegionLocator.getAllRegionLocations
[
https://issues.apache.org/jira/browse/HBASE-21770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751371#comment-16751371
]
Hadoop QA commented on HBASE-21770:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
39s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
7s{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} 5m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
58s{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
43s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
20s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}131m
57s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}188m 24s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21770 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12956154/HBASE-21770.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 56db790fd342 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct
31 10:55:11 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 / 416b70f461 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0
[jira] [Updated] (HBASE-21678) Port HBASE-20636 (Introduce two bloom filter type ROWPREFIX and ROWPREFIX_DELIMITED) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-21678: --- Resolution: Won't Fix Assignee: (was: Andrew Purtell) Fix Version/s: (was: 1.5.0) Status: Resolved (was: Patch Available) > Port HBASE-20636 (Introduce two bloom filter type ROWPREFIX and > ROWPREFIX_DELIMITED) to branch-1 > > > Key: HBASE-21678 > URL: https://issues.apache.org/jira/browse/HBASE-21678 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Priority: Major > Attachments: HBASE-21678-branch-1.patch, HBASE-21678-branch-1.patch, > HBASE-21678-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21678) Port HBASE-20636 (Introduce two bloom filter type ROWPREFIX and ROWPREFIX_DELIMITED) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751352#comment-16751352 ] Andrew Purtell commented on HBASE-21678: This hasn't attracted any reviews and is not critical for inclusion in 1.5. I thought it would be a nice to have based on some Phoenix related discussion at my workplace, but even then it's not a must have. That's fine. Resolving this as Wont Fix. > Port HBASE-20636 (Introduce two bloom filter type ROWPREFIX and > ROWPREFIX_DELIMITED) to branch-1 > > > Key: HBASE-21678 > URL: https://issues.apache.org/jira/browse/HBASE-21678 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21678-branch-1.patch, HBASE-21678-branch-1.patch, > HBASE-21678-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
