[jira] [Commented] (HBASE-21707) TestRSGroupsKillRS is not stable enough
[ https://issues.apache.org/jira/browse/HBASE-21707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741125#comment-16741125 ] Duo Zhang commented on HBASE-21707: --- OK, I think this is a test issue. We only have 1 RS in the group, and we killed it, so the region can not be assigned, thus we should not wait for no RIT after killing the server, we need to add new servers to the group... Let me fix the test... > TestRSGroupsKillRS is not stable enough > --- > > Key: HBASE-21707 > URL: https://issues.apache.org/jira/browse/HBASE-21707 > Project: HBase > Issue Type: Bug > Components: Region Assignment, rsgroup >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-21707-UT.patch > > > By adding a sleep after the stopServer call, the test will hang there > forever, need to dig more, maybe something wrong with the TRSP related stuffs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21707) TestRSGroupsKillRS is not stable enough
[ https://issues.apache.org/jira/browse/HBASE-21707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21707: -- Attachment: HBASE-21707-UT.patch > TestRSGroupsKillRS is not stable enough > --- > > Key: HBASE-21707 > URL: https://issues.apache.org/jira/browse/HBASE-21707 > Project: HBase > Issue Type: Bug > Components: Region Assignment, rsgroup >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-21707-UT.patch > > > By adding a sleep after the stopServer call, the test will hang there > forever, need to dig more, maybe something wrong with the TRSP related stuffs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21707) TestRSGroupsKillRS is not stable enough
Duo Zhang created HBASE-21707: - Summary: TestRSGroupsKillRS is not stable enough Key: HBASE-21707 URL: https://issues.apache.org/jira/browse/HBASE-21707 Project: HBase Issue Type: Bug Components: Region Assignment, rsgroup Reporter: Duo Zhang By adding a sleep after the stopServer call, the test will hang there forever, need to dig more, maybe something wrong with the TRSP related stuffs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21705: -- Attachment: HBASE-21705-v1.patch > Should treat meta table specially for some methods in AsyncAdmin > > > Key: HBASE-21705 > URL: https://issues.apache.org/jira/browse/HBASE-21705 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21705-v1.patch, HBASE-21705.patch > > > For example, tableExists, isTableEnabled, isTableDisabled... > For now, we will go to the meta table directly but obviously, meta table does > not contain the record for itself... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741016#comment-16741016 ] Duo Zhang commented on HBASE-21705: --- I think we'd better remove the check in AsyncMetaTableAccessor? As its name is for accessing meta table... > Should treat meta table specially for some methods in AsyncAdmin > > > Key: HBASE-21705 > URL: https://issues.apache.org/jira/browse/HBASE-21705 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21705.patch > > > For example, tableExists, isTableEnabled, isTableDisabled... > For now, we will go to the meta table directly but obviously, meta table does > not contain the record for itself... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21679) Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-21679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741009#comment-16741009
]
Hadoop QA commented on HBASE-21679:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
56s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
8s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
55s{color} | {color:green} branch-1 passed with JDK v1.8.0_192 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
43s{color} | {color:green} branch-1 passed with JDK v1.7.0_201 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 14m
29s{color} | {color:green} branch-1 passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 3m
56s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
59s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 8m
35s{color} | {color:green} branch-1 passed with JDK v1.8.0_192 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 7m
28s{color} | {color:green} branch-1 passed with JDK v1.7.0_201 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
27s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
26s{color} | {color:green} the patch passed with JDK v1.8.0_192 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
0s{color} | {color:green} the patch passed with JDK v1.7.0_201 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 2m 0s{color}
| {color:red} root-jdk1.7.0_201 with JDK v1.7.0_201 generated 2 new + 36
unchanged - 2 fixed = 38 total (was 38) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
54s{color} | {color:red} hbase-server: The patch generated 3 new + 561
unchanged - 11 fixed = 564 total (was 572) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 5m
29s{color} | {color:red} root: The patch generated 3 new + 773 unchanged - 11
fixed = 776 total (was 784) {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
15s{color} | {color:red} The patch generated 15 new + 912 unchanged - 12 fixed
= 927 total (was 924) {color} |
| {color:orange}-0{color} | {color:orange} ruby-lint {color} | {color:orange}
0m 5s{color} | {color:orange} The patch generated 10 new + 665 unchanged - 2
fixed = 675 total (was 667) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} xml {color} | {color:red} 0m 0s{color} |
{color:red} The patch has 1 ill-formed XML file(s). {color} |
| {color:blue}0{color} | {color:blue} refguide
[jira] [Commented] (HBASE-20716) Unsafe access cleanup
[
https://issues.apache.org/jira/browse/HBASE-20716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740999#comment-16740999
]
Hudson commented on HBASE-20716:
Results for branch branch-1
[build #629 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/629/]:
(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/629//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/629//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/629//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Unsafe access cleanup
> -
>
> Key: HBASE-20716
> URL: https://issues.apache.org/jira/browse/HBASE-20716
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
>Reporter: stack
>Assignee: Sahil Aggarwal
>Priority: Critical
> Labels: beginner
> Fix For: 3.0.0, 1.5.0, 2.2.0, 2.1.1
>
> Attachments: HBASE-20716.master.001.patch,
> HBASE-20716.master.002.patch, HBASE-20716.master.003.patch,
> HBASE-20716.master.004.patch, HBASE-20716.master.005.patch,
> HBASE-20716.master.006.patch, HBASE-20716.master.007.patch,
> HBASE-20716.master.008.patch, Screen Shot 2018-06-26 at 11.37.49 AM.png
>
>
> We have two means of getting at unsafe; UnsafeAccess and then internal to the
> Bytes class. They are effectively doing the same thing. We should have one
> avenue to Unsafe only.
> Many of our paths to Unsafe via UnsafeAccess traverse flags to check if
> access is available, if it is aligned and the order in which words are
> written on the machine. Each check costs -- especially if done millions of
> times a second -- and on occasion adds bloat in hot code paths. The unsafe
> access inside Bytes checks on startup what the machine is capable off and
> then does a static assign of the appropriate class-to-use from there on out.
> UnsafeAccess does not do this running the checks everytime. Would be good to
> have the Bytes behavior pervasive.
> The benefit of one access to Unsafe only is plain. The benefits we gain
> removing checks will be harder to measure though should be plain when you
> disassemble a hot-path; in a (very) rare case, the saved byte codes could be
> the difference between inlining or not.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20928) Rewrite calculation of midpoint in binarySearch functions to prevent overflow
[
https://issues.apache.org/jira/browse/HBASE-20928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741001#comment-16741001
]
Hudson commented on HBASE-20928:
Results for branch branch-1
[build #629 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/629/]:
(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/629//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/629//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/629//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Rewrite calculation of midpoint in binarySearch functions to prevent overflow
> -
>
> Key: HBASE-20928
> URL: https://issues.apache.org/jira/browse/HBASE-20928
> Project: HBase
> Issue Type: Bug
> Components: io
>Reporter: saurabh singh
>Assignee: saurabh singh
>Priority: Minor
> Fix For: 1.5.0, 2.2.0
>
> Attachments: HBASE-20928-addendum.patch,
> HBASE-20928-fix-binarySearch-v5.patch, HBASE-20928-fix-binarySearch-v5.patch
>
>
> There are couple of issues in the function:
> * {{>>>}} operator would mess the values if {{low}} + {{high}} end up being
> negative. This shouldn't happen but I don't see anything to prevent this from
> happening.
> * The code fails around boundary values of {{low}} and {{high}}. This is a
> well known binary search catch.
> [https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html]
>
> Most of the code should already be covered by tests. I would have liked to
> add a test that actually fails without the fix but given these are private
> methods I am not sure on the best place to add the test. Suggestions?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21208) Bytes#toShort doesn't work without unsafe
[
https://issues.apache.org/jira/browse/HBASE-21208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741000#comment-16741000
]
Hudson commented on HBASE-21208:
Results for branch branch-1
[build #629 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/629/]:
(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/629//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/629//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/629//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Bytes#toShort doesn't work without unsafe
> -
>
> Key: HBASE-21208
> URL: https://issues.apache.org/jira/browse/HBASE-21208
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Fix For: 1.5.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21208.v0.patch, HBASE-21208.v1.patch,
> HBASE-21208.v2.patch
>
>
> seems we put the brackets in the wrong place.
> {code}
> short n = 0;
> n = (short) ((n ^ bytes[offset]) & 0xFF);
> n = (short) (n << 8);
> n = (short) ((n ^ bytes[offset+1]) & 0xFF); // this one
> return n;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21164) reportForDuty to spew less log if master is initializing
[
https://issues.apache.org/jira/browse/HBASE-21164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741002#comment-16741002
]
Hudson commented on HBASE-21164:
Results for branch branch-1
[build #629 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/629/]:
(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/629//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/629//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/629//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> reportForDuty to spew less log if master is initializing
>
>
> Key: HBASE-21164
> URL: https://issues.apache.org/jira/browse/HBASE-21164
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
>Reporter: stack
>Assignee: Mingliang Liu
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.2.0, 2.1.1
>
> Attachments: HBASE-21164.005.patch, HBASE-21164.006.patch,
> HBASE-21164.007.patch, HBASE-21164.008.patch, HBASE-21164.009.patch,
> HBASE-21164.branch-2.1.001.patch, HBASE-21164.branch-2.1.002.patch,
> HBASE-21164.branch-2.1.003.patch, HBASE-21164.branch-2.1.004.patch
>
>
> RegionServers do reportForDuty on startup to tell Master they are available.
> If Master is initializing, and especially on a big cluster when it can take a
> while particularly if something is amiss, the log every three seconds is
> annoying and doesn't do anything of use. We should spew less those logs. Here
> is example:
> {code:java}
> 2018-09-06 14:01:39,312 INFO
> org.apache.hadoop.hbase.regionserver.HRegionServer: reportForDuty to
> master=vc0207.halxg.cloudera.com,22001,1536266763109 with port=22001,
> startcode=1536266763109
> 2018-09-06 14:01:39,312 WARN
> org.apache.hadoop.hbase.regionserver.HRegionServer: reportForDuty failed;
> sleeping and then retrying.
>
> {code}
> For example, I am looking at a large cluster now that had a backlog of
> procedure WALs. It is taking a couple of hours recreating the procedure-state
> because there are millions of procedures outstanding. Meantime, the Master
> log is just full of the above message – every three seconds...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21325) Force to terminate regionserver when abort hang in somewhere
[
https://issues.apache.org/jira/browse/HBASE-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16741003#comment-16741003
]
Hudson commented on HBASE-21325:
Results for branch branch-1
[build #629 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/629/]:
(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/629//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/629//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/629//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Force to terminate regionserver when abort hang in somewhere
>
>
> Key: HBASE-21325
> URL: https://issues.apache.org/jira/browse/HBASE-21325
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 3.0.0, 2.2.0, 2.1.1, 2.0.2
>Reporter: Duo Zhang
>Assignee: Guanghao Zhang
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.2.0
>
> Attachments: HBASE-21325.master.001.patch,
> HBASE-21325.master.001.patch, HBASE-21325.master.002.patch,
> HBASE-21325.master.003.patch, HBASE-21325.master.004.patch,
> HBASE-21325.master.005.patch
>
>
> When testing sync replication, I found that, if I transit the remote cluster
> to DA, while the local cluster is still in A, the region server will hang
> when shutdown. As the fsOk flag only test the local cluster(which is
> reasonable), we will enter the waitOnAllRegionsToClose, and since the WAL is
> broken(the remote wal directory is gone) so we will never succeed. And this
> lead to an infinite wait inside waitOnAllRegionsToClose.
> So I think here we should have an upper bound for the wait time in
> waitOnAllRegionsToClose method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21679) Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-21679: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) > Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1 > --- > > Key: HBASE-21679 > URL: https://issues.apache.org/jira/browse/HBASE-21679 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21679-branch-1.patch, HBASE-21679-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21693) [rsgroup] Do not attempt to move tables that do not exist
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740979#comment-16740979
]
Hadoop QA commented on HBASE-21693:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
12s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
11s{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 43s{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} 0m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 6m 33s{color}
| {color:red} hbase-rsgroup in the patch failed. {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} 36m 13s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.rsgroup.TestRSGroupsAdmin2 |
| | hadoop.hbase.rsgroup.TestRSGroupsBalance |
| | hadoop.hbase.rsgroup.TestRSGroupsWithACL |
| | hadoop.hbase.rsgroup.TestRSGroupsBasics |
| | hadoop.hbase.rsgroup.TestRSGroupsKillRS |
| | hadoop.hbase.rsgroup.TestRSGroupsOfflineMode |
| | hadoop.hbase.rsgroup.TestRSGroupsAdmin1 |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21693 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954665/HBASE-21693.master.0002.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 734016c442bb 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 / 3d2580cd6d |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| unit |
[jira] [Commented] (HBASE-21679) Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740963#comment-16740963 ] Andrew Purtell commented on HBASE-21679: Got a +1 on RB, thanks [~abhishek.chouhan]. Rebased again. Will commit if local checks pass. > Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1 > --- > > Key: HBASE-21679 > URL: https://issues.apache.org/jira/browse/HBASE-21679 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21679-branch-1.patch, HBASE-21679-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21325) Force to terminate regionserver when abort hang in somewhere
[ https://issues.apache.org/jira/browse/HBASE-21325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-21325: --- Fix Version/s: 1.5.0 > Force to terminate regionserver when abort hang in somewhere > > > Key: HBASE-21325 > URL: https://issues.apache.org/jira/browse/HBASE-21325 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0, 2.2.0, 2.1.1, 2.0.2 >Reporter: Duo Zhang >Assignee: Guanghao Zhang >Priority: Major > Fix For: 3.0.0, 1.5.0, 2.2.0 > > Attachments: HBASE-21325.master.001.patch, > HBASE-21325.master.001.patch, HBASE-21325.master.002.patch, > HBASE-21325.master.003.patch, HBASE-21325.master.004.patch, > HBASE-21325.master.005.patch > > > When testing sync replication, I found that, if I transit the remote cluster > to DA, while the local cluster is still in A, the region server will hang > when shutdown. As the fsOk flag only test the local cluster(which is > reasonable), we will enter the waitOnAllRegionsToClose, and since the WAL is > broken(the remote wal directory is gone) so we will never succeed. And this > lead to an infinite wait inside waitOnAllRegionsToClose. > So I think here we should have an upper bound for the wait time in > waitOnAllRegionsToClose method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21693) [rsgroup] Do not attempt to move tables that do not exist
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xuqinya updated HBASE-21693:
Attachment: HBASE-21693.master.0002.patch
Status: Patch Available (was: Open)
> [rsgroup] Do not attempt to move tables that do not exist
> -
>
> Key: HBASE-21693
> URL: https://issues.apache.org/jira/browse/HBASE-21693
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21693.master.0001.patch,
> HBASE-21693.master.0002.patch
>
>
> In rsgroup, allow to move tables that do not exist. This can cause dirty data.
> {code:java}
> base(main):004:0* move_rsgroup_tables 'rs1',['ttt']
> hbase(main):005:0> get_rsgroup 'rs1'
> GROUP INFORMATION
> Servers:
> 192.168.12.65:16020
> Tables:
> ttt
> {code}
>
> I think it should be like this. As follows:
> {code:java}
> hbase(main):001:0> move_rsgroup_tables 'rs1',['ttt']
> ERROR: org.apache.hadoop.hbase.constraint.ConstraintException: Source group
> is null for table ttt ,table must exist.
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:265)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveTables(RSGroupAdminEndpoint.java:174)
> at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:11141)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:675)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:52454)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Here is some help for this command:
> Reassign tables from one group to another.
> hbase> move_rsgroup_tables 'dest',['table1','table2']
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21673) Final sweep of branch-2+ commits for new branch-1 minor (1.5)
[ https://issues.apache.org/jira/browse/HBASE-21673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740962#comment-16740962 ] Andrew Purtell edited comment on HBASE-21673 at 1/12/19 2:03 AM: - Cherry picked and pushed HBASE-20716, HBASE-20928, HBASE-21164, HBASE-21208, and HBASE-21325. was (Author: apurtell): Backported and pushed HBASE-20716, HBASE-20928, HBASE-21164, HBASE-21208, and HBASE-21325. > Final sweep of branch-2+ commits for new branch-1 minor (1.5) > - > > Key: HBASE-21673 > URL: https://issues.apache.org/jira/browse/HBASE-21673 > Project: HBase > Issue Type: Umbrella >Affects Versions: 1.5.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > > Umbrella for backports to branch-1 of suitable changes for a new minor (1.5). > See subtasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21673) Final sweep of branch-2+ commits for new branch-1 minor (1.5)
[ https://issues.apache.org/jira/browse/HBASE-21673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740962#comment-16740962 ] Andrew Purtell commented on HBASE-21673: Backported and pushed HBASE-20716, HBASE-20928, HBASE-21164, HBASE-21208, and HBASE-21325. > Final sweep of branch-2+ commits for new branch-1 minor (1.5) > - > > Key: HBASE-21673 > URL: https://issues.apache.org/jira/browse/HBASE-21673 > Project: HBase > Issue Type: Umbrella >Affects Versions: 1.5.0 >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > > Umbrella for backports to branch-1 of suitable changes for a new minor (1.5). > See subtasks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work stopped] (HBASE-21693) [rsgroup] Do not attempt to move tables that do not exist
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-21693 stopped by xuqinya.
---
> [rsgroup] Do not attempt to move tables that do not exist
> -
>
> Key: HBASE-21693
> URL: https://issues.apache.org/jira/browse/HBASE-21693
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21693.master.0001.patch,
> HBASE-21693.master.0002.patch
>
>
> In rsgroup, allow to move tables that do not exist. This can cause dirty data.
> {code:java}
> base(main):004:0* move_rsgroup_tables 'rs1',['ttt']
> hbase(main):005:0> get_rsgroup 'rs1'
> GROUP INFORMATION
> Servers:
> 192.168.12.65:16020
> Tables:
> ttt
> {code}
>
> I think it should be like this. As follows:
> {code:java}
> hbase(main):001:0> move_rsgroup_tables 'rs1',['ttt']
> ERROR: org.apache.hadoop.hbase.constraint.ConstraintException: Source group
> is null for table ttt ,table must exist.
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:265)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveTables(RSGroupAdminEndpoint.java:174)
> at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:11141)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:675)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:52454)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Here is some help for this command:
> Reassign tables from one group to another.
> hbase> move_rsgroup_tables 'dest',['table1','table2']
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21693) [rsgroup] Do not attempt to move tables that do not exist
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740953#comment-16740953
]
Andrew Purtell commented on HBASE-21693:
The idea behind this change is good and it looks reasonable but the patch needs
more work because it causes existing unit tests to fail. Please set this issue
to 'Patch Available', wait for precommit, check the unit test failures, and
work on it until the latest patch finally passes all unit tests.
I see these failures:
[ERROR] TestRSGroupsAdmin1.testDisabledTableMove:391 » Constraint
org.apache.hadoop.hb...
[ERROR]
org.apache.hadoop.hbase.rsgroup.TestRSGroupsAdmin1.testFailRemoveGroup(org.apache.hadoop.hbase.rsgroup.TestRSGroupsAdmin1)
[ERROR] TestRSGroupsAdmin1.testFailRemoveGroup:241 » Constraint
org.apache.hadoop.hbas...
[ERROR] TestRSGroupsAdmin1.testMultiTableMove:278 » Constraint
org.apache.hadoop.hbase...
[ERROR]
TestRSGroupsAdmin1.testRSGroupListDoesNotContainFailedTableCreation:463 »
Constraint
[ERROR] TestRSGroupsAdmin1.testTableMoveTruncateAndDrop:330 » Constraint
org.apache.ha...
[ERROR] Tests run: 14, Failures: 0, Errors: 5, Skipped: 0
> [rsgroup] Do not attempt to move tables that do not exist
> -
>
> Key: HBASE-21693
> URL: https://issues.apache.org/jira/browse/HBASE-21693
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21693.master.0001.patch
>
>
> In rsgroup, allow to move tables that do not exist. This can cause dirty data.
> {code:java}
> base(main):004:0* move_rsgroup_tables 'rs1',['ttt']
> hbase(main):005:0> get_rsgroup 'rs1'
> GROUP INFORMATION
> Servers:
> 192.168.12.65:16020
> Tables:
> ttt
> {code}
>
> I think it should be like this. As follows:
> {code:java}
> hbase(main):001:0> move_rsgroup_tables 'rs1',['ttt']
> ERROR: org.apache.hadoop.hbase.constraint.ConstraintException: Source group
> is null for table ttt ,table must exist.
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:265)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveTables(RSGroupAdminEndpoint.java:174)
> at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:11141)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:675)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:52454)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Here is some help for this command:
> Reassign tables from one group to another.
> hbase> move_rsgroup_tables 'dest',['table1','table2']
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21693) [rsgroup] Do not attempt to move tables that do not exist
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740950#comment-16740950
]
xuqinya commented on HBASE-21693:
-
[~apurtell] , Thank you for your review.
> [rsgroup] Do not attempt to move tables that do not exist
> -
>
> Key: HBASE-21693
> URL: https://issues.apache.org/jira/browse/HBASE-21693
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21693.master.0001.patch
>
>
> In rsgroup, allow to move tables that do not exist. This can cause dirty data.
> {code:java}
> base(main):004:0* move_rsgroup_tables 'rs1',['ttt']
> hbase(main):005:0> get_rsgroup 'rs1'
> GROUP INFORMATION
> Servers:
> 192.168.12.65:16020
> Tables:
> ttt
> {code}
>
> I think it should be like this. As follows:
> {code:java}
> hbase(main):001:0> move_rsgroup_tables 'rs1',['ttt']
> ERROR: org.apache.hadoop.hbase.constraint.ConstraintException: Source group
> is null for table ttt ,table must exist.
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:265)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveTables(RSGroupAdminEndpoint.java:174)
> at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:11141)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:675)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:52454)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Here is some help for this command:
> Reassign tables from one group to another.
> hbase> move_rsgroup_tables 'dest',['table1','table2']
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21693) [rsgroup] Do not attempt to move tables that do not exist
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-21693:
---
Summary: [rsgroup] Do not attempt to move tables that do not exist (was:
rsgroup's bug when moving bogus tables)
> [rsgroup] Do not attempt to move tables that do not exist
> -
>
> Key: HBASE-21693
> URL: https://issues.apache.org/jira/browse/HBASE-21693
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21693.master.0001.patch
>
>
> In rsgroup, allow to move tables that do not exist. This can cause dirty data.
> {code:java}
> base(main):004:0* move_rsgroup_tables 'rs1',['ttt']
> hbase(main):005:0> get_rsgroup 'rs1'
> GROUP INFORMATION
> Servers:
> 192.168.12.65:16020
> Tables:
> ttt
> {code}
>
> I think it should be like this. As follows:
> {code:java}
> hbase(main):001:0> move_rsgroup_tables 'rs1',['ttt']
> ERROR: org.apache.hadoop.hbase.constraint.ConstraintException: Source group
> is null for table ttt ,table must exist.
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:265)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveTables(RSGroupAdminEndpoint.java:174)
> at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:11141)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:675)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:52454)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Here is some help for this command:
> Reassign tables from one group to another.
> hbase> move_rsgroup_tables 'dest',['table1','table2']
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21679) Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-21679: --- Attachment: HBASE-21679-branch-1.patch > Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1 > --- > > Key: HBASE-21679 > URL: https://issues.apache.org/jira/browse/HBASE-21679 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21679-branch-1.patch, HBASE-21679-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21679) Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740943#comment-16740943 ] Andrew Purtell commented on HBASE-21679: Updated patch. Rebased on latest branch-1. Warnings in RSRpcServices cannot be fixed, they are deprecated API warnings for Signal. Addressed HRegion warnings. Unrelated to this change, but still. Addressed what rubocop warnings I could. Unit test failures are not locally reproducible and appear unrelated, probably environmental. ruby-lint warnings are invalid. Fixed whitespace. XML warning is invalid. It's the "script engine for language js can not be found" issue. > Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1 > --- > > Key: HBASE-21679 > URL: https://issues.apache.org/jira/browse/HBASE-21679 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21679-branch-1.patch, HBASE-21679-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-21693) rsgroup's bug when moving bogus tables
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-21693 started by xuqinya.
---
> rsgroup's bug when moving bogus tables
> --
>
> Key: HBASE-21693
> URL: https://issues.apache.org/jira/browse/HBASE-21693
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21693.master.0001.patch
>
>
> In rsgroup, allow to move tables that do not exist. This can cause dirty data.
> {code:java}
> base(main):004:0* move_rsgroup_tables 'rs1',['ttt']
> hbase(main):005:0> get_rsgroup 'rs1'
> GROUP INFORMATION
> Servers:
> 192.168.12.65:16020
> Tables:
> ttt
> {code}
>
> I think it should be like this. As follows:
> {code:java}
> hbase(main):001:0> move_rsgroup_tables 'rs1',['ttt']
> ERROR: org.apache.hadoop.hbase.constraint.ConstraintException: Source group
> is null for table ttt ,table must exist.
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:265)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveTables(RSGroupAdminEndpoint.java:174)
> at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:11141)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:675)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:52454)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Here is some help for this command:
> Reassign tables from one group to another.
> hbase> move_rsgroup_tables 'dest',['table1','table2']
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21164) reportForDuty to spew less log if master is initializing
[
https://issues.apache.org/jira/browse/HBASE-21164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-21164:
---
Fix Version/s: 1.5.0
> reportForDuty to spew less log if master is initializing
>
>
> Key: HBASE-21164
> URL: https://issues.apache.org/jira/browse/HBASE-21164
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
>Reporter: stack
>Assignee: Mingliang Liu
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 2.2.0, 2.1.1
>
> Attachments: HBASE-21164.005.patch, HBASE-21164.006.patch,
> HBASE-21164.007.patch, HBASE-21164.008.patch, HBASE-21164.009.patch,
> HBASE-21164.branch-2.1.001.patch, HBASE-21164.branch-2.1.002.patch,
> HBASE-21164.branch-2.1.003.patch, HBASE-21164.branch-2.1.004.patch
>
>
> RegionServers do reportForDuty on startup to tell Master they are available.
> If Master is initializing, and especially on a big cluster when it can take a
> while particularly if something is amiss, the log every three seconds is
> annoying and doesn't do anything of use. We should spew less those logs. Here
> is example:
> {code:java}
> 2018-09-06 14:01:39,312 INFO
> org.apache.hadoop.hbase.regionserver.HRegionServer: reportForDuty to
> master=vc0207.halxg.cloudera.com,22001,1536266763109 with port=22001,
> startcode=1536266763109
> 2018-09-06 14:01:39,312 WARN
> org.apache.hadoop.hbase.regionserver.HRegionServer: reportForDuty failed;
> sleeping and then retrying.
>
> {code}
> For example, I am looking at a large cluster now that had a backlog of
> procedure WALs. It is taking a couple of hours recreating the procedure-state
> because there are millions of procedures outstanding. Meantime, the Master
> log is just full of the above message – every three seconds...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21679) Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740926#comment-16740926 ] Andrew Purtell edited comment on HBASE-21679 at 1/12/19 12:58 AM: -- To make forward progress on umbrella I'm going to commit this as lazy consensus. First, will fix the precommit warnings was (Author: apurtell): To make forward progress on umbrella I'm going to commit this as lazy consensus > Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1 > --- > > Key: HBASE-21679 > URL: https://issues.apache.org/jira/browse/HBASE-21679 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21679-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21679) Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-21679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740926#comment-16740926 ] Andrew Purtell commented on HBASE-21679: To make forward progress on umbrella I'm going to commit this as lazy consensus > Port HBASE-6028 (Start/Stop compactions at region server level) to branch-1 > --- > > Key: HBASE-21679 > URL: https://issues.apache.org/jira/browse/HBASE-21679 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-21679-branch-1.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21634) Print error message when user uses unacceptable values for LIMIT while setting quotas.
[
https://issues.apache.org/jira/browse/HBASE-21634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740925#comment-16740925
]
Sakthi commented on HBASE-21634:
[~zghaobac] / [~elserj] Mind taking a look at the patch? Thanks.
> Print error message when user uses unacceptable values for LIMIT while
> setting quotas.
> --
>
> Key: HBASE-21634
> URL: https://issues.apache.org/jira/browse/HBASE-21634
> Project: HBase
> Issue Type: Improvement
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Attachments: hbase-21634.master.001.patch,
> hbase-21634.master.002.patch, hbase-21634.master.003.patch,
> hbase-21634.master.004.patch
>
>
> When unacceptable value(like 2.3G or 70H) to LIMIT are passed while setting
> quotas, we currently do not print any error message (informing the user about
> the erroneous input). Like below:
> {noformat}
> hbase(main):002:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '2.3G',
> POLICY => NO_WRITES
> Took 0.0792 seconds
> hbase(main):003:0> list_quotas
> OWNERQUOTAS
> TABLE => t2 TYPE => SPACE,
> TABLE => t2, LIMIT => 2B, VIOLATION_POLICY => NO_WRITES
> 1 row(s)
> Took 0.0512 seconds
> hbase(main):006:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '70H',
> POLICY => NO_WRITES
> Took 0.0088 seconds
> hbase(main):007:0> list_quotas
> OWNERQUOTAS
> TABLE => t2 TYPE => SPACE,
> TABLE => t2, LIMIT => 70B, VIOLATION_POLICY => NO_WRITES
> 1 row(s)
> Took 0.0448 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21693) rsgroup's bug when moving bogus tables
[
https://issues.apache.org/jira/browse/HBASE-21693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740924#comment-16740924
]
Andrew Purtell commented on HBASE-21693:
+1
Committing after some local checks
> rsgroup's bug when moving bogus tables
> --
>
> Key: HBASE-21693
> URL: https://issues.apache.org/jira/browse/HBASE-21693
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Reporter: xuqinya
>Assignee: xuqinya
>Priority: Major
> Attachments: HBASE-21693.master.0001.patch
>
>
> In rsgroup, allow to move tables that do not exist. This can cause dirty data.
> {code:java}
> base(main):004:0* move_rsgroup_tables 'rs1',['ttt']
> hbase(main):005:0> get_rsgroup 'rs1'
> GROUP INFORMATION
> Servers:
> 192.168.12.65:16020
> Tables:
> ttt
> {code}
>
> I think it should be like this. As follows:
> {code:java}
> hbase(main):001:0> move_rsgroup_tables 'rs1',['ttt']
> ERROR: org.apache.hadoop.hbase.constraint.ConstraintException: Source group
> is null for table ttt ,table must exist.
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminServer.moveTables(RSGroupAdminServer.java:265)
> at
> org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpoint.moveTables(RSGroupAdminEndpoint.java:174)
> at
> org.apache.hadoop.hbase.protobuf.generated.RSGroupAdminProtos$RSGroupAdminService.callMethod(RSGroupAdminProtos.java:11141)
> at
> org.apache.hadoop.hbase.master.MasterRpcServices.execMasterService(MasterRpcServices.java:675)
> at
> org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:52454)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2135)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:133)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:108)
> at java.lang.Thread.run(Thread.java:745)
> Here is some help for this command:
> Reassign tables from one group to another.
> hbase> move_rsgroup_tables 'dest',['table1','table2']
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740922#comment-16740922
]
Sakthi commented on HBASE-21225:
Hey [~elserj], the failed UT looks unrelated. It passed locally. Rest of the QA
looks fine.
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-21225.master.001.patch,
> hbase-21225.master.002.patch, hbase-21225.master.003.patch,
> hbase-21225.master.004.patch, hbase-21225.master.005.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
>MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
>ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740914#comment-16740914
]
Hadoop QA commented on HBASE-21225:
---
| (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} 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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
27s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
15s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
2s{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
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
53s{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
5s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 54s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
35s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
28s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}148m 23s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
45s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}207m 1s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestHbck |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21225 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954636/hbase-21225.master.005.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux cf63acc3b75c 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 / 3d2580cd6d |
| maven | version: Apache Maven 3.5.4
[jira] [Commented] (HBASE-21456) Make WALFactory only used for creating WALProviders
[
https://issues.apache.org/jira/browse/HBASE-21456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740883#comment-16740883
]
Ankit Singhal commented on HBASE-21456:
---
{quote}Do we reach a consensus, or any info i needed to be synced?
{quote}
{quote}I have similar sort of question: whats wrong w/ WALFactory being the
place you go to to manufacture anything to do w/ WALs...? Obviously you have
some larger plan in mind. Is there a pointer? Thanks.
{quote}
Sorry [~reidchan], I thought consensus was reached after your comment, but it
seems not ,that's my bad.
[~stack], I think(and this probably was also the same thought when Josh
created this Jira) that currently there is a confusion in responsibility of
walFactory vs walProvider. As with new API's added in walProvider, it is better
to access walProvider directly instead creating a shim for them in the factory
and on the other hand , we can redefine WalFactory (or WalProviderFactory) to
just help in initializing the configured WAL provider and let other WAL related
stuff to provider itself.
But that's all said, would like to hear your thought on the need of having
WalFactory intercepting all the request made to the provider.
> Make WALFactory only used for creating WALProviders
> ---
>
> Key: HBASE-21456
> URL: https://issues.apache.org/jira/browse/HBASE-21456
> Project: HBase
> Issue Type: Sub-task
> Components: wal
>Reporter: Josh Elser
>Assignee: Ankit Singhal
>Priority: Major
> Attachments: HBASE-21456.HBASE-20952.001.patch,
> HBASE-21456.HBASE-20952.wip.patch
>
>
> As a Factory, WALFactory should only have one job: creating instances of
> WALProvider.
> However, over the years, it has been a landing place for lots of wal-related
> methods (e.g. constructing readers, WALEntryStream, and more). We want all of
> this to live in the WALProvider.
> We can do this in two steps: have the WALFactory methods invoke the method on
> the WALProvider (handled elsewhere), then here we can replace usage of the
> WALFactory "wrapper methods" with the WALProvider itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (HBASE-17384) Consider aborting region server when MVCC#waitForRead() gets stuck
[
https://issues.apache.org/jira/browse/HBASE-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-17384.
---
Resolution: Won't Fix
No work done on this improvement and better to fix why we are STUCK than do a
workaround.
> Consider aborting region server when MVCC#waitForRead() gets stuck
> --
>
> Key: HBASE-17384
> URL: https://issues.apache.org/jira/browse/HBASE-17384
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Priority: Major
> Attachments: testHRegionWithInMemoryFlush.out
>
>
> From
> https://builds.apache.org/job/PreCommit-HBASE-Build/5072/testReport/org.apache.hadoop.hbase.regionserver/TestHRegionWithInMemoryFlush/org_apache_hadoop_hbase_regionserver_TestHRegionWithInMemoryFlush/
> :
> {code}
> org.junit.runners.model.TestTimedOutException: test timed out after 10 minutes
> at java.lang.Object.wait(Native Method)
> at
> org.apache.hadoop.hbase.regionserver.MultiVersionConcurrencyControl.waitForRead(MultiVersionConcurrencyControl.java:218)
> at
> org.apache.hadoop.hbase.regionserver.MultiVersionConcurrencyControl.completeAndWait(MultiVersionConcurrencyControl.java:149)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.getNextSequenceId(HRegion.java:2732)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalPrepareFlushCache(HRegion.java:2447)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2343)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2314)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2304)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1601)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1506)
> at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1456)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.closeRegionAndWAL(HBaseTestingUtility.java:374)
> at
> org.apache.hadoop.hbase.regionserver.TestHRegion.testFlushCacheWhileScanning(TestHRegion.java:3839)
> {code}
> As can be seen from test output:
> {code}
> 2016-12-28 13:43:28,379 INFO [Time-limited test] regionserver.HStore(1431):
> Completed major compaction of 1 (all) file(s) in family1 of
> testWritesWhileScanning,,1482932605883.2e46061b97a54d7f8434c4a705b3c4a2. into
> 255e7eb61cfc4945ac5887957d39b1fe(size=98.0 K), total size for store is 98.0 K
> ...[truncated 4062267 bytes]...
> TUCK: MultiVersionConcurrencyControl{readPoint=1090, writePoint=1093}
> 2016-12-28 13:48:29,396 WARN [Time-limited test]
> regionserver.MultiVersionConcurrencyControl(214): STUCK:
> MultiVersionConcurrencyControl{readPoint=1090, writePoint=1093}
> 2016-12-28 13:48:30,406 WARN [Time-limited test]
> regionserver.MultiVersionConcurrencyControl(214): STUCK:
> MultiVersionConcurrencyControl{readPoint=1090, writePoint=1093}
> 2016-12-28 13:48:31,416 WARN [Time-limited test]
> regionserver.MultiVersionConcurrencyControl(214): STUCK:
> MultiVersionConcurrencyControl{readPoint=1090, writePoint=1093}
> {code}
> At least 5 minutes passed with the above log showing waitForRead() stuck.
> Since the flush is blocked, we should consider aborting region server when
> waitForRead() gets stuck for extended period of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21706) Inconsistency of fs.defaultFS between active and standby masters
[
https://issues.apache.org/jira/browse/HBASE-21706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lei Chen updated HBASE-21706:
-
Description:
I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
standby masters have different `fs.defaultFS` on their /conf pages.
Given `fs.defaultFS` is set to : and `hbase.rootdir` is set
to :/ in core-site.xml on all the hosts, it looks
like standby masters has `fs.defaultFS` programatically set to the same value
as `hbase.rootdir`.
For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
following line on the /conf page
{code:java}
fs.defaultFShdfs://DEV-CLUSTERprogramatically
{code}
but standby masters has
{code:java}
fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
Please correct me if this is not a bug but a feature, however I find this
behavior surprising plus I cannot locate any related document.
>From a quick looking at the code, the cause seems to be that standby masters
>got the property set in
>[HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
>[MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
was:
I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
standby masters have different `fs.defaultFS` on their /conf pages.
Given `fs.defaultFS` is set to : and `hbase.rootdir` is set
to :/ in core-site.xml on all the hosts, it looks
like standby masters has `fs.defaultFS` programatically set to the same value
as `hbase.rootdir`.
For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
following line on the /conf page
{code:java}
fs.defaultFShdfs://DEV-CLUSTERprogramatically
{code}
but standby masters has
{code:java}
fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
Please correct me if this is not a bug but a feature, but I find this behavior
surprising plus I cannot locate any related document.
>From a quick looking at the code, the cause seems to be that standby masters
>got the property set in
>[HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
>[MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
> Inconsistency of fs.defaultFS between active and standby masters
>
>
> Key: HBASE-21706
> URL: https://issues.apache.org/jira/browse/HBASE-21706
> Project: HBase
> Issue Type: Bug
> Components: conf, master
>Affects Versions: 1.1.2
>Reporter: Lei Chen
>Priority: Minor
>
> I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
> standby masters have different `fs.defaultFS` on their /conf pages.
> Given `fs.defaultFS` is set to : and `hbase.rootdir` is
> set to :/ in core-site.xml on all the hosts, it
> looks like standby masters has `fs.defaultFS` programatically set to the same
> value as `hbase.rootdir`.
> For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
> following line on the /conf page
> {code:java}
> fs.defaultFShdfs://DEV-CLUSTERprogramatically
> {code}
> but standby masters has
> {code:java}
> fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
> Please correct me if this is not a bug but a feature, however I find this
> behavior surprising plus I cannot locate any related document.
> From a quick looking at the code, the cause seems to be that standby masters
> got the property set in
> [HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
> [MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21706) Inconsistency of fs.defaultFS between active and standby masters
[
https://issues.apache.org/jira/browse/HBASE-21706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lei Chen updated HBASE-21706:
-
Description:
I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
standby masters have different `fs.defaultFS` on their /conf pages.
Given `fs.defaultFS` is set to : and `hbase.rootdir` is set
to :/ in core-site.xml on all the hosts, it looks
like standby masters has `fs.defaultFS` programatically set to the same value
as `hbase.rootdir`.
For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
following line on the /conf page
{code:java}
fs.defaultFShdfs://DEV-CLUSTERprogramatically
{code}
but standby masters has
{code:java}
fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
Please correct me if this is not a bug but a feature, however I find this
behavior surprising plus I cannot locate any related document.
>From a quick look at the code, the cause seems to be that standby masters got
>the property set in
>[HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
>[MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
was:
I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
standby masters have different `fs.defaultFS` on their /conf pages.
Given `fs.defaultFS` is set to : and `hbase.rootdir` is set
to :/ in core-site.xml on all the hosts, it looks
like standby masters has `fs.defaultFS` programatically set to the same value
as `hbase.rootdir`.
For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
following line on the /conf page
{code:java}
fs.defaultFShdfs://DEV-CLUSTERprogramatically
{code}
but standby masters has
{code:java}
fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
Please correct me if this is not a bug but a feature, however I find this
behavior surprising plus I cannot locate any related document.
>From a quick looking at the code, the cause seems to be that standby masters
>got the property set in
>[HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
>[MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
> Inconsistency of fs.defaultFS between active and standby masters
>
>
> Key: HBASE-21706
> URL: https://issues.apache.org/jira/browse/HBASE-21706
> Project: HBase
> Issue Type: Bug
> Components: conf, master
>Affects Versions: 1.1.2
>Reporter: Lei Chen
>Priority: Minor
>
> I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
> standby masters have different `fs.defaultFS` on their /conf pages.
> Given `fs.defaultFS` is set to : and `hbase.rootdir` is
> set to :/ in core-site.xml on all the hosts, it
> looks like standby masters has `fs.defaultFS` programatically set to the same
> value as `hbase.rootdir`.
> For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
> following line on the /conf page
> {code:java}
> fs.defaultFShdfs://DEV-CLUSTERprogramatically
> {code}
> but standby masters has
> {code:java}
> fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
> Please correct me if this is not a bug but a feature, however I find this
> behavior surprising plus I cannot locate any related document.
> From a quick look at the code, the cause seems to be that standby masters got
> the property set in
> [HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
> [MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740814#comment-16740814
]
Josh Elser commented on HBASE-21225:
Looks OK. Let's see what QA says.
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-21225.master.001.patch,
> hbase-21225.master.002.patch, hbase-21225.master.003.patch,
> hbase-21225.master.004.patch, hbase-21225.master.005.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
>MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
>ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
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=16740805#comment-16740805
]
Josh Elser commented on HBASE-20662:
{quote}
Both scenarios fail with current logic with/without patch.
I have provided a fix and test for these scenarios t
{quote}
What was the change that you made? I'm diff'ing your previous patch to try to
figure this out.
{code}
> -LOG.trace(currentSnapshots.size() + " table quota snapshots are
> collected, "
> -+ "read " + newSnapshots.size() + " from the quota table.");
> +LOG.trace("{} table quota snapshots are collected, read {} from the
> quota table.",
> + currentSnapshots.size(), newSnapshots.size());
{code}
Please undo these logger changes in this patch. If you want to switch over to
the slf4j marker API, you should also be removing the {{ifTraceEnabled()}}
wrapping conditional blocks too. Best to focus on one thing for a patch as this
makes your change much easier for everyone else to follow.
> 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
>
>
> *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
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740799#comment-16740799
]
Sakthi commented on HBASE-21225:
Oh yes. It would be wise to have the previous tests. I have restored the tests
and have modified testTableSpaceAndRPCQuotaRemoved,
testNamespaceSpaceAndRPCQuotaRemoved. Have uploaded the new patch, [~elserj].
Let me know :)
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-21225.master.001.patch,
> hbase-21225.master.002.patch, hbase-21225.master.003.patch,
> hbase-21225.master.004.patch, hbase-21225.master.005.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
>MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
>ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21500) Jetty aliases parameter need to change as per jetty 9.x version
[ https://issues.apache.org/jira/browse/HBASE-21500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740798#comment-16740798 ] Josh Elser commented on HBASE-21500: [~nihaljain.cs], what does this property do? We have no test coverage for whatever is being exposed? > Jetty aliases parameter need to change as per jetty 9.x version > --- > > Key: HBASE-21500 > URL: https://issues.apache.org/jira/browse/HBASE-21500 > Project: HBase > Issue Type: Bug >Affects Versions: 3.0.0, 2.1.0, 2.0.0, 2.0.1, 2.1.1 >Reporter: Bhupendra Kumar Jain >Assignee: Nihal Jain >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-21500.master.001.patch > > > Noticed that Jetty aliases parameter in HttpServer.java > "*org.mortbay.jetty.servlet.Default.aliases*" is as per old jetty version and > need to change as per jetty 9.x new version after the HBASE-12894 > Refer > https://github.com/apache/hbase/blob/405bf5e6383a09f435baadbac6c389e9f6c43ac6/hbase-http/src/main/java/org/apache/hadoop/hbase/http/HttpServer.java#L647 > It should be *"org.eclipse.jetty.servlet.Default.aliases"* -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-21225:
---
Attachment: hbase-21225.master.005.patch
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-21225.master.001.patch,
> hbase-21225.master.002.patch, hbase-21225.master.003.patch,
> hbase-21225.master.004.patch, hbase-21225.master.005.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
>MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
>ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21706) Inconsistency of fs.defaultFS between active and standby masters
[
https://issues.apache.org/jira/browse/HBASE-21706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lei Chen updated HBASE-21706:
-
Description:
I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
standby masters have different `fs.defaultFS` on their /conf pages.
Given `fs.defaultFS` is set to : and `hbase.rootdir` is set
to :/ in core-site.xml on all the hosts, it looks
like standby masters has `fs.defaultFS` programatically set to the same value
as `hbase.rootdir`.
For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
following line on the /conf page
{code:java}
fs.defaultFShdfs://DEV-CLUSTERprogramatically
{code}
but standby masters has
{code:java}
fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
Please correct me if this is not a bug but a feature, but I find this behavior
surprising plus I cannot locate any related document.
>From a quick looking at the code, the cause seems to be that standby masters
>got the property set in
>[HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
>[MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
was:
I'm using HDP-2.3.6.22-1 with HBase HA configured. I noticed that active and
standby masters have different `fs.defaultFS` on their /conf pages.
Given `fs.defaultFS` is set to : and `hbase.rootdir` is set
to :/ in core-site.xml on all the hosts, it looks
like standby masters has `fs.defaultFS` programatically set to the same value
as `hbase.rootdir`.
For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
following line on the /conf page
{code:java}
fs.defaultFShdfs://DEV-CLUSTERprogramatically
{code}
but standby masters has
{code:java}
fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
Please correct me if this is not a bug but a feature, but I find this behavior
surprising plus I cannot locate any related document.
>From a quick looking at the code, the cause seems to be that standby masters
>got the property set in
>[HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
>[MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
> Inconsistency of fs.defaultFS between active and standby masters
>
>
> Key: HBASE-21706
> URL: https://issues.apache.org/jira/browse/HBASE-21706
> Project: HBase
> Issue Type: Bug
> Components: conf, master
>Affects Versions: 1.1.2
>Reporter: Lei Chen
>Priority: Minor
>
> I'm using HDP-2.6.3.22-1 with HBase HA configured. I noticed that active and
> standby masters have different `fs.defaultFS` on their /conf pages.
> Given `fs.defaultFS` is set to : and `hbase.rootdir` is
> set to :/ in core-site.xml on all the hosts, it
> looks like standby masters has `fs.defaultFS` programatically set to the same
> value as `hbase.rootdir`.
> For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
> following line on the /conf page
> {code:java}
> fs.defaultFShdfs://DEV-CLUSTERprogramatically
> {code}
> but standby masters has
> {code:java}
> fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
> Please correct me if this is not a bug but a feature, but I find this
> behavior surprising plus I cannot locate any related document.
> From a quick looking at the code, the cause seems to be that standby masters
> got the property set in
> [HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
> [MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21706) Inconsistency of fs.defaultFS between active and standby masters
Lei Chen created HBASE-21706:
Summary: Inconsistency of fs.defaultFS between active and standby
masters
Key: HBASE-21706
URL: https://issues.apache.org/jira/browse/HBASE-21706
Project: HBase
Issue Type: Bug
Components: conf, master
Affects Versions: 1.1.2
Reporter: Lei Chen
I'm using HDP-2.3.6.22-1 with HBase HA configured. I noticed that active and
standby masters have different `fs.defaultFS` on their /conf pages.
Given `fs.defaultFS` is set to : and `hbase.rootdir` is set
to :/ in core-site.xml on all the hosts, it looks
like standby masters has `fs.defaultFS` programatically set to the same value
as `hbase.rootdir`.
For example, on a 3 heads cluster DEV-CLUSTER, my active master has the
following line on the /conf page
{code:java}
fs.defaultFShdfs://DEV-CLUSTERprogramatically
{code}
but standby masters has
{code:java}
fs.defaultFShdfs://DEV-CLUSTER/hbase-rootprogramatically{code}
Please correct me if this is not a bug but a feature, but I find this behavior
surprising plus I cannot locate any related document.
>From a quick looking at the code, the cause seems to be that standby masters
>got the property set in
>[HRegionServer.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L649-L652],
> and active master got it set in a different way in
>[MasterFileSystem.java|https://github.com/hortonworks/hbase-release/blob/HDP-2.6.3.22-tag/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java#L132-L137].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740766#comment-16740766
]
Josh Elser commented on HBASE-21225:
[~jatsakthi], the current patch looks OK, but I can't help but feel like you
have removed test coverage for just a space quota and just a throttle quota.
Normally I wouldn't care too much because deleting a space/throttle in the case
where there are also other quotas is more complicated, but we've had "broken"
logic around this once already.
Can we restore {{testTableSpaceQuotaRemoved}} and {{testTableRPCQuotaRemoved}}?
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-21225.master.001.patch,
> hbase-21225.master.002.patch, hbase-21225.master.003.patch,
> hbase-21225.master.004.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
>MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
>ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740761#comment-16740761
]
Sakthi commented on HBASE-21225:
How does the patch look [~elserj]? Any further scope for improvements?
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-21225.master.001.patch,
> hbase-21225.master.002.patch, hbase-21225.master.003.patch,
> hbase-21225.master.004.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
>MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
>ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[
https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740756#comment-16740756
]
Josh Elser commented on HBASE-21702:
{quote}On the current website I don't even see how to get to the hbasecon
archive landing page.
{quote}
Yeah, ClayB contributed some HTML direct to us that bypasses the normal site
build (didn't want to look that gift horse in the mouth)
Will take some more time to slice and dice what we have to be a bit more
"normal".
> Transcribe "what is HBaseCon" into book
> ---
>
> Key: HBASE-21702
> URL: https://issues.apache.org/jira/browse/HBASE-21702
> Project: HBase
> Issue Type: Task
> Components: documentation
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch
>
>
> Take the document I wrote on google docs
> (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit)
> and get it into the HBase book.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21208) Bytes#toShort doesn't work without unsafe
[
https://issues.apache.org/jira/browse/HBASE-21208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-21208:
---
Fix Version/s: 1.5.0
> Bytes#toShort doesn't work without unsafe
> -
>
> Key: HBASE-21208
> URL: https://issues.apache.org/jira/browse/HBASE-21208
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Fix For: 1.5.0, 2.2.0, 2.1.1, 2.0.3
>
> Attachments: HBASE-21208.v0.patch, HBASE-21208.v1.patch,
> HBASE-21208.v2.patch
>
>
> seems we put the brackets in the wrong place.
> {code}
> short n = 0;
> n = (short) ((n ^ bytes[offset]) & 0xFF);
> n = (short) (n << 8);
> n = (short) ((n ^ bytes[offset+1]) & 0xFF); // this one
> return n;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20928) Rewrite calculation of midpoint in binarySearch functions to prevent overflow
[
https://issues.apache.org/jira/browse/HBASE-20928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-20928:
---
Fix Version/s: 1.5.0
> Rewrite calculation of midpoint in binarySearch functions to prevent overflow
> -
>
> Key: HBASE-20928
> URL: https://issues.apache.org/jira/browse/HBASE-20928
> Project: HBase
> Issue Type: Bug
> Components: io
>Reporter: saurabh singh
>Assignee: saurabh singh
>Priority: Minor
> Fix For: 1.5.0, 2.2.0
>
> Attachments: HBASE-20928-addendum.patch,
> HBASE-20928-fix-binarySearch-v5.patch, HBASE-20928-fix-binarySearch-v5.patch
>
>
> There are couple of issues in the function:
> * {{>>>}} operator would mess the values if {{low}} + {{high}} end up being
> negative. This shouldn't happen but I don't see anything to prevent this from
> happening.
> * The code fails around boundary values of {{low}} and {{high}}. This is a
> well known binary search catch.
> [https://ai.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html]
>
> Most of the code should already be covered by tests. I would have liked to
> add a test that actually fails without the fix but given these are private
> methods I am not sure on the best place to add the test. Suggestions?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740726#comment-16740726 ] Sean Busbey commented on HBASE-21702: - wouldn't updating the website still require a patch? On the current website I don't even see how to get to the hbasecon archive landing page. > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20716) Unsafe access cleanup
[ https://issues.apache.org/jira/browse/HBASE-20716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-20716: --- Fix Version/s: 1.5.0 > Unsafe access cleanup > - > > Key: HBASE-20716 > URL: https://issues.apache.org/jira/browse/HBASE-20716 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: stack >Assignee: Sahil Aggarwal >Priority: Critical > Labels: beginner > Fix For: 3.0.0, 1.5.0, 2.2.0, 2.1.1 > > Attachments: HBASE-20716.master.001.patch, > HBASE-20716.master.002.patch, HBASE-20716.master.003.patch, > HBASE-20716.master.004.patch, HBASE-20716.master.005.patch, > HBASE-20716.master.006.patch, HBASE-20716.master.007.patch, > HBASE-20716.master.008.patch, Screen Shot 2018-06-26 at 11.37.49 AM.png > > > We have two means of getting at unsafe; UnsafeAccess and then internal to the > Bytes class. They are effectively doing the same thing. We should have one > avenue to Unsafe only. > Many of our paths to Unsafe via UnsafeAccess traverse flags to check if > access is available, if it is aligned and the order in which words are > written on the machine. Each check costs -- especially if done millions of > times a second -- and on occasion adds bloat in hot code paths. The unsafe > access inside Bytes checks on startup what the machine is capable off and > then does a static assign of the appropriate class-to-use from there on out. > UnsafeAccess does not do this running the checks everytime. Would be good to > have the Bytes behavior pervasive. > The benefit of one access to Unsafe only is plain. The benefits we gain > removing checks will be harder to measure though should be plain when you > disassemble a hot-path; in a (very) rare case, the saved byte codes could be > the difference between inlining or not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740739#comment-16740739 ] stack commented on HBASE-21702: --- Content is great. Yeah, updating hbasecon pages requires patch? Our poor old hbasecon archive/pages need love too > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740709#comment-16740709
]
Josh Elser commented on HBASE-21225:
{quote}the reason I was trying to remove the "remove" attribute was, I saw that
throttle quota's implementation didn't seem to have a "remove" attribute and
wanted to keep both the implementations as similar as possible
{quote}
IMO, the implementation of the ThrottleQuota is strange. It's really
complicated for no apparent reason to me :). It's not a gold-standard to hold
other code to for me.
> Having RPC & Space quota on a table/Namespace doesn't allow space quota to be
> removed using 'NONE'
> --
>
> Key: HBASE-21225
> URL: https://issues.apache.org/jira/browse/HBASE-21225
> Project: HBase
> Issue Type: Bug
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-21225.master.001.patch,
> hbase-21225.master.002.patch, hbase-21225.master.003.patch,
> hbase-21225.master.004.patch
>
>
> A part of HBASE-20705 is still unresolved. In that Jira it was assumed that
> problem is: when table having both rpc & space quotas is dropped (with
> hbase.quota.remove.on.table.delete set as true), the rpc quota is not set to
> be dropped along with table-drops, and space quota was not being able to be
> removed completely because of the "EMPTY" row that rpc quota left even after
> removing.
> The proposed solution for that was to make sure that rpc quota didn't leave
> empty rows after removal of quota. And setting automatic removal of rpc quota
> with table drops. That made sure that space quotas can be recreated/removed.
> But all this was under the assumption that hbase.quota.remove.on.table.delete
> is set as true. When it is set as false, the same issue can reproduced. Also
> the below shown steps can used to reproduce the issue without table-drops.
> {noformat}
> hbase(main):005:0> create 't2','cf'
> Created table t2
> Took 0.7619 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0514 seconds
> hbase(main):007:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0162 seconds
> hbase(main):008:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE,
> LIMIT => 10M/sec, SCOPE =>
>MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824,
> VIOLATION_POLICY => NO_WRIT
>ES
> 2 row(s)
> Took 0.0716 seconds
> hbase(main):009:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => NONE
> Took 0.0082 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0254 seconds
> hbase(main):011:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0082 seconds
> hbase(main):012:0> list_quotas
> OWNER QUOTAS
> TABLE => t2TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> TABLE => t2TYPE => SPACE, TABLE => t2, REMOVE => true
> 2 row(s)
> Took 0.0411 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740707#comment-16740707 ] Josh Elser commented on HBASE-21702: You happy with the content as presented, [~stack]? Assuming no further chatter, I'll just close this out and update the website. > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740701#comment-16740701 ] stack commented on HBASE-21702: --- bq. Where you thinking instead of the book Stack? Maybe on the HBaseCon archive part of the website? I think this a good idea. > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740652#comment-16740652
]
Hudson commented on HBASE-21704:
Results for branch branch-2.1
[build #762 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/762/]:
(/) *{color:green}+1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/762//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/762//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/762//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> The implementation of DistributedHBaseCluster.getServerHoldingRegion is
> incorrect
> -
>
> Key: HBASE-21704
> URL: https://issues.apache.org/jira/browse/HBASE-21704
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21704.patch
>
>
> The parameter is a regionName, but in the method, it will get a region
> locator for the table, and pass the use the regionName to locate the region,
> but actually, the parameter of the getRegionLocation method is row, not
> regionName...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21663) Add replica scan support
[
https://issues.apache.org/jira/browse/HBASE-21663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740644#comment-16740644
]
Hudson commented on HBASE-21663:
Results for branch branch-2
[build #1604 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add replica scan support
>
>
> Key: HBASE-21663
> URL: https://issues.apache.org/jira/browse/HBASE-21663
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, read replicas
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21663-v1.patch, HBASE-21663.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740645#comment-16740645
]
Hudson commented on HBASE-21704:
Results for branch branch-2
[build #1604 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> The implementation of DistributedHBaseCluster.getServerHoldingRegion is
> incorrect
> -
>
> Key: HBASE-21704
> URL: https://issues.apache.org/jira/browse/HBASE-21704
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21704.patch
>
>
> The parameter is a regionName, but in the method, it will get a region
> locator for the table, and pass the use the regionName to locate the region,
> but actually, the parameter of the getRegionLocation method is row, not
> regionName...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21580) Support getting Hbck instance from AsyncConnection
[
https://issues.apache.org/jira/browse/HBASE-21580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740643#comment-16740643
]
Hudson commented on HBASE-21580:
Results for branch branch-2
[build #1604 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1604//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Support getting Hbck instance from AsyncConnection
> --
>
> Key: HBASE-21580
> URL: https://issues.apache.org/jira/browse/HBASE-21580
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, hbck2
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21580.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21295) Update compatibility matrices
[
https://issues.apache.org/jira/browse/HBASE-21295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740633#comment-16740633
]
Hudson commented on HBASE-21295:
Results for branch master
[build #714 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/714/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/714//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/714//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/714//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Update compatibility matrices
> -
>
> Key: HBASE-21295
> URL: https://issues.apache.org/jira/browse/HBASE-21295
> Project: HBase
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.0.0
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Minor
> Attachments: HBASE-21295-v1.patch, HBASE-21295-v2.patch,
> HBASE-21295.master.001.patch
>
>
> JDK and Hadoop compatibility matrices does not cover all of the current
> releases and available JDKs. These should be added to both tables.
> [https://hbase.apache.org/book.html#hadoop]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740634#comment-16740634
]
Hudson commented on HBASE-21704:
Results for branch master
[build #714 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/714/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/714//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/714//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/714//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> The implementation of DistributedHBaseCluster.getServerHoldingRegion is
> incorrect
> -
>
> Key: HBASE-21704
> URL: https://issues.apache.org/jira/browse/HBASE-21704
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21704.patch
>
>
> The parameter is a regionName, but in the method, it will get a region
> locator for the table, and pass the use the regionName to locate the region,
> but actually, the parameter of the getRegionLocation method is row, not
> regionName...
--
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=16740623#comment-16740623
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #50 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/50/]:
(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/50//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/50//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/50//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-21596) HBase Shell "delete" command can cause older versions to be shown even if VERSIONS is configured as 1
[ https://issues.apache.org/jira/browse/HBASE-21596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740611#comment-16740611 ] Sean Busbey commented on HBASE-21596: - is this fall out from the changes in HBASE-18142? > HBase Shell "delete" command can cause older versions to be shown even if > VERSIONS is configured as 1 > - > > Key: HBASE-21596 > URL: https://issues.apache.org/jira/browse/HBASE-21596 > Project: HBase > Issue Type: Bug >Reporter: Wellington Chevreuil >Assignee: Wellington Chevreuil >Priority: Minor > Attachments: HBASE-21596-master.001.patch, initial-patch.txt > > > HBase Shell delete command is supposed to operate over an specific TS. If no > TS is informed, it will assume the latest TS for the cell and put delete > marker for it. > However, for a CF with VERSIONS => 1, if multiple puts were performed for > same cell, there may be multiple cell versions on the memstore, so delete > would only be "delete marking" one of those, and causing the most recent no > marked one to be shown on gets/scans, which then contradicts the CF "VERSIONS > => 1" configuration. > This issue is not seen with deleteall command or using Delete operation from > Java API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740615#comment-16740615
]
Hudson commented on HBASE-21704:
Results for branch branch-2.0
[build #1246 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1246/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1246//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1246//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1246//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> The implementation of DistributedHBaseCluster.getServerHoldingRegion is
> incorrect
> -
>
> Key: HBASE-21704
> URL: https://issues.apache.org/jira/browse/HBASE-21704
> Project: HBase
> Issue Type: Bug
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21704.patch
>
>
> The parameter is a regionName, but in the method, it will get a region
> locator for the table, and pass the use the regionName to locate the region,
> but actually, the parameter of the getRegionLocation method is row, not
> regionName...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740606#comment-16740606 ] Sean Busbey commented on HBASE-21702: - I like the additional text. Where you thinking instead of the book Stack? Maybe on the HBaseCon archive part of the website? > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[
https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740601#comment-16740601
]
Hadoop QA commented on HBASE-21702:
---
| (/) *{color:green}+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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
44s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
38s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
51s{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:blue}0{color} | {color:blue} refguide {color} | {color:blue} 6m
8s{color} | {color:blue} patch has no errors when building the reference guide.
See footer for rendered docs, which you should manually inspect. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 22m 8s{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-21702 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954611/HBASE-21702.002.patch
|
| Optional Tests | dupname asflicense refguide |
| uname | Linux 34c6e78ab662 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 / 3d2580cd6d |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/15545/artifact/patchprocess/branch-site/book.html
|
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/15545/artifact/patchprocess/patch-site/book.html
|
| Max. process+thread count | 87 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/15545/console |
| Powered by | Apache Yetus 0.8.0 http://yetus.apache.org |
This message was automatically generated.
> Transcribe "what is HBaseCon" into book
> ---
>
> Key: HBASE-21702
> URL: https://issues.apache.org/jira/browse/HBASE-21702
> Project: HBase
> Issue Type: Task
> Components: documentation
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch
>
>
> Take the document I wrote on google docs
> (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit)
> and get it into the HBase book.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740584#comment-16740584 ] Josh Elser commented on HBASE-21702: My thought was that book is easier to maintain than the website itself. Putting it on the website instead of book is fine – I don't carry much distinction between the two. > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-21702: --- Attachment: HBASE-21702.002.patch > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[ https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740581#comment-16740581 ] stack commented on HBASE-21702: --- Should this be in the book? The audience for this is minuscule? > Transcribe "what is HBaseCon" into book > --- > > Key: HBASE-21702 > URL: https://issues.apache.org/jira/browse/HBASE-21702 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > Attachments: HBASE-21702.001.patch, HBASE-21702.002.patch > > > Take the document I wrote on google docs > (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit) > and get it into the HBase book. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21580) Support getting Hbck instance from AsyncConnection
[ https://issues.apache.org/jira/browse/HBASE-21580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740580#comment-16740580 ] stack commented on HBASE-21580: --- +1 Do we have to make change in hbase-operator-tools to make use of this or is that just later? > Support getting Hbck instance from AsyncConnection > -- > > Key: HBASE-21580 > URL: https://issues.apache.org/jira/browse/HBASE-21580 > Project: HBase > Issue Type: Sub-task > Components: asyncclient, Client, hbck2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21580.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21663) Add replica scan support
[
https://issues.apache.org/jira/browse/HBASE-21663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740540#comment-16740540
]
Hudson commented on HBASE-21663:
Results for branch branch-2.1
[build #761 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add replica scan support
>
>
> Key: HBASE-21663
> URL: https://issues.apache.org/jira/browse/HBASE-21663
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, read replicas
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21663-v1.patch, HBASE-21663.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21580) Support getting Hbck instance from AsyncConnection
[
https://issues.apache.org/jira/browse/HBASE-21580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740539#comment-16740539
]
Hudson commented on HBASE-21580:
Results for branch branch-2.1
[build #761 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/761//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Support getting Hbck instance from AsyncConnection
> --
>
> Key: HBASE-21580
> URL: https://issues.apache.org/jira/browse/HBASE-21580
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, hbck2
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21580.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21663) Add replica scan support
[
https://issues.apache.org/jira/browse/HBASE-21663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740537#comment-16740537
]
Hudson commented on HBASE-21663:
Results for branch branch-2.0
[build #1245 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Add replica scan support
>
>
> Key: HBASE-21663
> URL: https://issues.apache.org/jira/browse/HBASE-21663
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, read replicas
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21663-v1.patch, HBASE-21663.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21580) Support getting Hbck instance from AsyncConnection
[
https://issues.apache.org/jira/browse/HBASE-21580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740536#comment-16740536
]
Hudson commented on HBASE-21580:
Results for branch branch-2.0
[build #1245 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/1245//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Support getting Hbck instance from AsyncConnection
> --
>
> Key: HBASE-21580
> URL: https://issues.apache.org/jira/browse/HBASE-21580
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, hbck2
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21580.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21702) Transcribe "what is HBaseCon" into book
[
https://issues.apache.org/jira/browse/HBASE-21702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740532#comment-16740532
]
Josh Elser commented on HBASE-21702:
{quote}I think it would really benefit from adding a sentence to the intro that
essentially says "folks who are interested in hosting a future HBaseCon event
should keep the following guidelines in mind and email the PMC via the mailing
list priv...@hbase.apache.org, which allows anyone to send messages, but
restricts who can read them"
{quote}
Just meant this to be a starting-point. Thanks for the suggestion. Let me try
to edit.
> Transcribe "what is HBaseCon" into book
> ---
>
> Key: HBASE-21702
> URL: https://issues.apache.org/jira/browse/HBASE-21702
> Project: HBase
> Issue Type: Task
> Components: documentation
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Major
> Attachments: HBASE-21702.001.patch
>
>
> Take the document I wrote on google docs
> (https://docs.google.com/document/d/15ZmgNKSzyR_UCzOmHEACnGZp-vuh-QlCYfr6bCmQ-4w/edit)
> and get it into the HBase book.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[
https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740502#comment-16740502
]
Hadoop QA commented on HBASE-21705:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
12s{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
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
51s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
30s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 52s{color}
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188
total (was 188) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
4s{color} | {color:red} hbase-server: The patch generated 4 new + 3 unchanged -
0 fixed = 7 total (was 3) {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
13s{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 37s{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
14s{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
18s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}130m
8s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
52s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}177m 16s{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-21705 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954584/HBASE-21705.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux be2d499d8580 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 / fbf79373e6 |
| maven | version: Apache Maven 3.5.4
[jira] [Commented] (HBASE-21537) Rewrite ServerManager.closeRegionSilentlyAndWait to use AsyncClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740470#comment-16740470
]
Hadoop QA commented on HBASE-21537:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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} HBASE-21512 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
51s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
2s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
36s{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
19s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} HBASE-21512 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
59s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
15s{color} | {color:red} hbase-server: The patch generated 3 new + 20 unchanged
- 2 fixed = 23 total (was 22) {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
34s{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 40s{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
23s{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:red}-1{color} | {color:red} unit {color} | {color:red}136m 35s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}178m 9s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.replication.TestSyncReplicationActive |
| | hadoop.hbase.master.TestRestartCluster |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21537 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954579/HBASE-21537-HBASE-21512.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 590dcf7f2bee 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 | HBASE-21512 / d6fbe51363 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
[jira] [Commented] (HBASE-21019) Use StealJobQueue to better utilize handlers in MasterFifoRpcScheduler
[ https://issues.apache.org/jira/browse/HBASE-21019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740401#comment-16740401 ] Guanghao Zhang commented on HBASE-21019: Ping [~Apache9] [~stack] for reviewing. > Use StealJobQueue to better utilize handlers in MasterFifoRpcScheduler > -- > > Key: HBASE-21019 > URL: https://issues.apache.org/jira/browse/HBASE-21019 > Project: HBase > Issue Type: Improvement >Affects Versions: 3.0.0, 2.2.0 >Reporter: Yi Mei >Assignee: Guanghao Zhang >Priority: Major > Attachments: HBASE-21019.master.001.patch, > HBASE-21019.master.001.patch, HBASE-21019.master.001.patch > > > In HBASE-20965, we propose MasterFifoRpcScheduler to handle RSReport requests > in independent handlers, other requests are handled in other handlers. > To better utilize handlers, we can use StealJobQueue to allow other handlers > to steal jobs from RSReport handlers when there is a few RSReport handlers. > And it's the same for SimpleRpcScheduler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740391#comment-16740391 ] Guanghao Zhang commented on HBASE-21705: +1 for others. > Should treat meta table specially for some methods in AsyncAdmin > > > Key: HBASE-21705 > URL: https://issues.apache.org/jira/browse/HBASE-21705 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21705.patch > > > For example, tableExists, isTableEnabled, isTableDisabled... > For now, we will go to the meta table directly but obviously, meta table does > not contain the record for itself... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740390#comment-16740390 ] Guanghao Zhang commented on HBASE-21705: There is a check for META Table in AsyncMetaTableAccessor#tableExists > Should treat meta table specially for some methods in AsyncAdmin > > > Key: HBASE-21705 > URL: https://issues.apache.org/jira/browse/HBASE-21705 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21705.patch > > > For example, tableExists, isTableEnabled, isTableDisabled... > For now, we will go to the meta table directly but obviously, meta table does > not contain the record for itself... -- 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=16740389#comment-16740389
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #49 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/49/]:
(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/49//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/49//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/49//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] [Resolved] (HBASE-21685) Change repository urls to Gitbox
[ https://issues.apache.org/jira/browse/HBASE-21685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi resolved HBASE-21685. --- Resolution: Fixed Repositories are in sync now. > Change repository urls to Gitbox > > > Key: HBASE-21685 > URL: https://issues.apache.org/jira/browse/HBASE-21685 > Project: HBase > Issue Type: Task >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0 > > Attachments: HBASE-21685.master.001.patch, > HBASE-21685.master.001.patch > > > Moving to Gitbox is approaching and references to git-wip-us need to be > changed to gitbox. > Some of the Jenkins jobs are referring to git-wip-us which if going to be > locked after the migration. We could move them to github so the build flow > will remain intact. > Previous discussion on dev@: > [https://lists.apache.org/thread.html/3496568d6cc002f74f5c3bcce46ed44b7ee9e90d7d53af2c65b6f785@%3Cdev.hbase.apache.org%3E] > After this notify INFRA to make the change -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[ https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740373#comment-16740373 ] Duo Zhang commented on HBASE-21704: --- I do not think the failed UT is related to the changes here, but maybe it is introduced by HBASE-21580, where we double the execution time for TestHbck. Will keep an eye on it. > The implementation of DistributedHBaseCluster.getServerHoldingRegion is > incorrect > - > > Key: HBASE-21704 > URL: https://issues.apache.org/jira/browse/HBASE-21704 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21704.patch > > > The parameter is a regionName, but in the method, it will get a region > locator for the table, and pass the use the regionName to locate the region, > but actually, the parameter of the getRegionLocation method is row, not > regionName... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21705: -- Assignee: Duo Zhang Fix Version/s: 2.0.5 2.1.3 2.2.0 3.0.0 Status: Patch Available (was: Open) > Should treat meta table specially for some methods in AsyncAdmin > > > Key: HBASE-21705 > URL: https://issues.apache.org/jira/browse/HBASE-21705 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21705.patch > > > For example, tableExists, isTableEnabled, isTableDisabled... > For now, we will go to the meta table directly but obviously, meta table does > not contain the record for itself... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21580) Support getting Hbck instance from AsyncConnection
[
https://issues.apache.org/jira/browse/HBASE-21580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740354#comment-16740354
]
Hudson commented on HBASE-21580:
Results for branch master
[build #713 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/713/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/713//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/713//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/713//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Support getting Hbck instance from AsyncConnection
> --
>
> Key: HBASE-21580
> URL: https://issues.apache.org/jira/browse/HBASE-21580
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, hbck2
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21580.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21663) Add replica scan support
[
https://issues.apache.org/jira/browse/HBASE-21663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740355#comment-16740355
]
Hudson commented on HBASE-21663:
Results for branch master
[build #713 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/713/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/713//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/713//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/713//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Add replica scan support
>
>
> Key: HBASE-21663
> URL: https://issues.apache.org/jira/browse/HBASE-21663
> Project: HBase
> Issue Type: Sub-task
> Components: asyncclient, Client, read replicas
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5
>
> Attachments: HBASE-21663-v1.patch, HBASE-21663.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21705: -- Component/s: Client asyncclient Admin > Should treat meta table specially for some methods in AsyncAdmin > > > Key: HBASE-21705 > URL: https://issues.apache.org/jira/browse/HBASE-21705 > Project: HBase > Issue Type: Sub-task > Components: Admin, asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21705.patch > > > For example, tableExists, isTableEnabled, isTableDisabled... > For now, we will go to the meta table directly but obviously, meta table does > not contain the record for itself... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-21705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21705: -- Attachment: HBASE-21705.patch > Should treat meta table specially for some methods in AsyncAdmin > > > Key: HBASE-21705 > URL: https://issues.apache.org/jira/browse/HBASE-21705 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-21705.patch > > > For example, tableExists, isTableEnabled, isTableDisabled... > For now, we will go to the meta table directly but obviously, meta table does > not contain the record for itself... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[
https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740352#comment-16740352
]
Hadoop QA commented on HBASE-21704:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
16s{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
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
7s{color} | {color:green} hbase-server: The patch generated 0 new + 5
unchanged - 1 fixed = 5 total (was 6) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s{color} | {color:green} The patch passed checkstyle in hbase-it {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
8s{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 49s{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
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}132m 43s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
1s{color} | {color:green} hbase-it in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
51s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}174m 34s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestHbck |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21704 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954565/HBASE-21704.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 273f640fccbb 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2
17:16:02 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Created] (HBASE-21705) Should treat meta table specially for some methods in AsyncAdmin
Duo Zhang created HBASE-21705: - Summary: Should treat meta table specially for some methods in AsyncAdmin Key: HBASE-21705 URL: https://issues.apache.org/jira/browse/HBASE-21705 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang For example, tableExists, isTableEnabled, isTableDisabled... For now, we will go to the meta table directly but obviously, meta table does not contain the record for itself... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21537) Rewrite ServerManager.closeRegionSilentlyAndWait to use AsyncClusterConnection
[ https://issues.apache.org/jira/browse/HBASE-21537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21537: -- Assignee: Duo Zhang Status: Patch Available (was: Open) > Rewrite ServerManager.closeRegionSilentlyAndWait to use AsyncClusterConnection > -- > > Key: HBASE-21537 > URL: https://issues.apache.org/jira/browse/HBASE-21537 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21537-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21537) Rewrite ServerManager.closeRegionSilentlyAndWait to use AsyncClusterConnection
[ https://issues.apache.org/jira/browse/HBASE-21537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21537: -- Attachment: HBASE-21537-HBASE-21512.patch > Rewrite ServerManager.closeRegionSilentlyAndWait to use AsyncClusterConnection > -- > > Key: HBASE-21537 > URL: https://issues.apache.org/jira/browse/HBASE-21537 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Priority: Major > Attachments: HBASE-21537-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21671) Rewrite RegionReplicaReplicationEndpoint to use AsyncClusterConnection
[ https://issues.apache.org/jira/browse/HBASE-21671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21671: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch HBASE-21512. Thanks [~tianjingyun] for reviewing. > Rewrite RegionReplicaReplicationEndpoint to use AsyncClusterConnection > -- > > Key: HBASE-21671 > URL: https://issues.apache.org/jira/browse/HBASE-21671 > Project: HBase > Issue Type: Sub-task > Components: read replicas >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21671-HBASE-21512-v1.patch, > HBASE-21671-HBASE-21512-v2.patch, HBASE-21671-HBASE-21512-v3.patch, > HBASE-21671-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21671) Rewrite RegionReplicaReplicationEndpoint to use AsyncClusterConnection
[ https://issues.apache.org/jira/browse/HBASE-21671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21671: -- Fix Version/s: HBASE-21512 > Rewrite RegionReplicaReplicationEndpoint to use AsyncClusterConnection > -- > > Key: HBASE-21671 > URL: https://issues.apache.org/jira/browse/HBASE-21671 > Project: HBase > Issue Type: Sub-task > Components: read replicas >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: HBASE-21512 > > Attachments: HBASE-21671-HBASE-21512-v1.patch, > HBASE-21671-HBASE-21512-v2.patch, HBASE-21671-HBASE-21512-v3.patch, > HBASE-21671-HBASE-21512.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-19695) Handle disabled table for async client
[ https://issues.apache.org/jira/browse/HBASE-19695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740318#comment-16740318 ] Duo Zhang commented on HBASE-19695: --- OK, seems the isTableDisabled method in AsyncAdmin does not handle meta table correctly. Let me fix. > Handle disabled table for async client > -- > > Key: HBASE-19695 > URL: https://issues.apache.org/jira/browse/HBASE-19695 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-19695-v1.patch, HBASE-19695.master.001.patch, > HBASE-19695.master.002.patch, HBASE-19695.patch > > > Now for async client we will not check if a table is disabled when retrying, > so we will retry until the time or count limit is reached, and will not throw > a TableNotEnabledException. > We should have the same behavior as sync client, but the implementation > should be carefully designed. For sync client, we will also check if a table > is disabled if it is a retry, no matter what the exception is. This will > double the pressure on meta table. We should try our best to eliminate > unnecessary access to meta table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21671) Rewrite RegionReplicaReplicationEndpoint to use AsyncClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740306#comment-16740306
]
Hadoop QA commented on HBASE-21671:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21512 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
43s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
48s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
32s{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
12s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} HBASE-21512 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
40s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 40s{color}
| {color:red} hbase-client generated 1 new + 99 unchanged - 1 fixed = 100 total
(was 100) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{color} | {color:green} The patch passed checkstyle in hbase-client {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} hbase-server: The patch generated 0 new + 7
unchanged - 6 fixed = 7 total (was 13) {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
34s{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 35s{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
37s{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
8s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}136m 12s{color}
| {color:red} hbase-server in the patch failed. {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}187m 5s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.replication.TestSyncReplicationActive |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21671 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954550/HBASE-21671-HBASE-21512-v3.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 108fd5b2f7d0
[jira] [Commented] (HBASE-19695) Handle disabled table for async client
[
https://issues.apache.org/jira/browse/HBASE-19695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740302#comment-16740302
]
Hadoop QA commented on HBASE-19695:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
22s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
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} 3m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
57s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s{color} | {color:green} hbase-client: The patch generated 0 new + 0
unchanged - 1 fixed = 0 total (was 1) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
13s{color} | {color:red} hbase-server: The patch generated 2 new + 1 unchanged
- 0 fixed = 3 total (was 1) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
32s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 47s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
2s{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} 3m
16s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}156m 39s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
51s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}209m 48s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncTableGetMultiThreaded |
| | hadoop.hbase.replication.TestReplicationDroppedTables |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-19695 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954546/HBASE-19695-v1.patch |
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 80e36a932377
[jira] [Commented] (HBASE-21225) Having RPC & Space quota on a table/Namespace doesn't allow space quota to be removed using 'NONE'
[
https://issues.apache.org/jira/browse/HBASE-21225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740300#comment-16740300
]
Hadoop QA commented on HBASE-21225:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
29s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
55s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
48s{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} 3m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
56s{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
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
45s{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
39s{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 47s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
18s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}155m 9s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
43s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}208m 20s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.multiwal.TestReplicationKillMasterRSCompressedWithMultipleWAL
|
| |
hadoop.hbase.replication.multiwal.TestReplicationKillMasterRSCompressedWithMultipleAsyncWAL
|
| | hadoop.hbase.replication.TestReplicationDroppedTables |
| | hadoop.hbase.client.TestHbck |
| | hadoop.hbase.replication.TestReplicationKillMasterRSCompressed |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21225 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12954547/hbase-21225.master.004.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux d1607e0b9375
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[ https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740236#comment-16740236 ] Guanghao Zhang commented on HBASE-21704: +1 > The implementation of DistributedHBaseCluster.getServerHoldingRegion is > incorrect > - > > Key: HBASE-21704 > URL: https://issues.apache.org/jira/browse/HBASE-21704 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21704.patch > > > The parameter is a regionName, but in the method, it will get a region > locator for the table, and pass the use the regionName to locate the region, > but actually, the parameter of the getRegionLocation method is row, not > regionName... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[ https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21704: -- Fix Version/s: 2.0.5 2.1.3 2.2.0 3.0.0 > The implementation of DistributedHBaseCluster.getServerHoldingRegion is > incorrect > - > > Key: HBASE-21704 > URL: https://issues.apache.org/jira/browse/HBASE-21704 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.3, 2.0.5 > > Attachments: HBASE-21704.patch > > > The parameter is a regionName, but in the method, it will get a region > locator for the table, and pass the use the regionName to locate the region, > but actually, the parameter of the getRegionLocation method is row, not > regionName... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21704) The implementation of DistributedHBaseCluster.getServerHoldingRegion is incorrect
[ https://issues.apache.org/jira/browse/HBASE-21704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740226#comment-16740226 ] Duo Zhang commented on HBASE-21704: --- Pass start key instead of regionName when calling RegionLocator.getRegionLocation. > The implementation of DistributedHBaseCluster.getServerHoldingRegion is > incorrect > - > > Key: HBASE-21704 > URL: https://issues.apache.org/jira/browse/HBASE-21704 > Project: HBase > Issue Type: Bug >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21704.patch > > > The parameter is a regionName, but in the method, it will get a region > locator for the table, and pass the use the regionName to locate the region, > but actually, the parameter of the getRegionLocation method is row, not > regionName... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
