[jira] [Commented] (HBASE-18990) ServerLoad doesn't override #equals which leads to #equals in ClusterStatus always false
[
https://issues.apache.org/jira/browse/HBASE-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203074#comment-16203074
]
Hadoop QA commented on HBASE-18990:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
30s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
23s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s{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
25s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
45m 24s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m
19s{color} | {color:red} hbase-client generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
52s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}100m
2s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
29s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}173m 4s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-client |
| | org.apache.hadoop.hbase.ServerLoad defines equals and uses
Object.hashCode() At ServerLoad.java:Object.hashCode() At
ServerLoad.java:[lines 370-384] |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18990 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891960/HBASE-18990.master.001.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6a59f1374060 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
[jira] [Created] (HBASE-19003) Make sure all balancer actions respect decommissioned server
Jerry He created HBASE-19003: Summary: Make sure all balancer actions respect decommissioned server Key: HBASE-19003 URL: https://issues.apache.org/jira/browse/HBASE-19003 Project: HBase Issue Type: Sub-task Reporter: Jerry He There have been questions raised in HBASE-10367 and other related JIRAs. We want to make sure all aspects of the balancer respect the draining flag. We will have a good look, and fix if any violation is found. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10367) RegionServer graceful stop / decommissioning
[
https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203052#comment-16203052
]
Hadoop QA commented on HBASE-10367:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{color} | {color:blue} Docker mode activated. {color} |
| {color: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 5 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for branch {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} 5m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
3s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
46s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 5m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
3s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
1s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} 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}
37m 59s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
3m 41s{color} | {color:green} the patch passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
27s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
31s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 92m
19s{color} |
[jira] [Commented] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()
[ https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203047#comment-16203047 ] ramkrishna.s.vasudevan commented on HBASE-18960: Just left few questions in RB. Not sure on what exactly was the bug with nonce. If you can put up here the case then it will be easy to review. > A few bug fixes and minor improvements around batchMutate() > --- > > Key: HBASE-18960 > URL: https://issues.apache.org/jira/browse/HBASE-18960 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 2.0.0-alpha-3 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18960.master.001.patch, > hbase-18960.master.002.patch, hbase-18960.master.003.patch, > hbase-18960.master.004.patch, hbase-18960.master.005.patch, > hbase-18960.master.005.patch, hbase-18960.master.006.patch, > hbase-18960.master.007.patch > > > Batch validation and preparation can be done before we start iterating over > batch operations for writes. observedExceptions, familyCellMaps and > durability can be stored in BatchOperation as they are batch wide. For all > operations, done by preBatchMutate() CP hook, operation status needs to be > SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10367) RegionServer graceful stop / decommissioning
[
https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203034#comment-16203034
]
Hadoop QA commented on HBASE-10367:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m
13s{color} | {color:red} Docker failed to build yetus/hbase:5d60123. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-10367 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891968/HBASE-10367-master-2.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9090/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> RegionServer graceful stop / decommissioning
>
>
> Key: HBASE-10367
> URL: https://issues.apache.org/jira/browse/HBASE-10367
> Project: HBase
> Issue Type: Improvement
>Reporter: Enis Soztutar
>Assignee: Jerry He
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-10367-master-2.patch, HBASE-10367-master.patch,
> HBASE-10367-master.patch
>
>
> Right now, we have a weird way of node decommissioning / graceful stop, which
> is a graceful_stop.sh bash script, and a region_mover ruby script, and some
> draining server support which you have to manually write to a znode
> (really!). Also draining servers is only partially supported in LB operations
> (LB does take that into account for roundRobin assignment, but not for normal
> balance)
> See
> http://hbase.apache.org/book/node.management.html and HBASE-3071
> I think we should support graceful stop as a first class citizen. Thinking
> about it, it seems that the difference between regionserver stop and graceful
> stop is that regionserver stop will close the regions, but the master will
> only assign them after the znode is deleted.
> In the new master design (or even before), if we allow RS to be able to close
> regions on its own (without master initiating it), then graceful stop becomes
> regular stop. The RS already closes the regions cleanly, and will reject new
> region assignments, so that we don't need much of the balancer or draining
> server trickery.
> This ties into the new master/AM redesign (HBASE-5487), but still deserves
> it's own jira. Let's use this to brainstorm on the design.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203030#comment-16203030 ] Josh Elser commented on HBASE-18901: bq. This is definitely a defect. Let me see if I can come up with a fix for it. I'm baffled as to why this doesn't fail normally. The docker image I was using to test... somehow compiles rpc-serde.cc without version.h. Very weird. bq. haven't reproduced this one yet myself Reproduced this too. Will see if I can figure out what the difference. I'm guessing that CMake is picking up the wrong version of the protobuf library -- will have to see. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203029#comment-16203029 ] Josh Elser commented on HBASE-18901: bq. version.h is a generated file which is generated from the mvn build, and gets copied from its original place via bin/copy-version.h. Also the makefile and buck calls bin/copy-protobuf.sh as well. This is definitely a defect. Let me see if I can come up with a fix for it. bq. do you guys see the same? Still working through it, but haven't reproduced this one yet myself. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-10367) RegionServer graceful stop / decommissioning
[ https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry He updated HBASE-10367: - Attachment: HBASE-10367-master-2.patch > RegionServer graceful stop / decommissioning > > > Key: HBASE-10367 > URL: https://issues.apache.org/jira/browse/HBASE-10367 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Jerry He > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-10367-master-2.patch, HBASE-10367-master.patch, > HBASE-10367-master.patch > > > Right now, we have a weird way of node decommissioning / graceful stop, which > is a graceful_stop.sh bash script, and a region_mover ruby script, and some > draining server support which you have to manually write to a znode > (really!). Also draining servers is only partially supported in LB operations > (LB does take that into account for roundRobin assignment, but not for normal > balance) > See > http://hbase.apache.org/book/node.management.html and HBASE-3071 > I think we should support graceful stop as a first class citizen. Thinking > about it, it seems that the difference between regionserver stop and graceful > stop is that regionserver stop will close the regions, but the master will > only assign them after the znode is deleted. > In the new master design (or even before), if we allow RS to be able to close > regions on its own (without master initiating it), then graceful stop becomes > regular stop. The RS already closes the regions cleanly, and will reject new > region assignments, so that we don't need much of the balancer or draining > server trickery. > This ties into the new master/AM redesign (HBASE-5487), but still deserves > it's own jira. Let's use this to brainstorm on the design. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-10367) RegionServer graceful stop / decommissioning
[ https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry He updated HBASE-10367: - Attachment: (was: HBASE-10367-master-2.patch) > RegionServer graceful stop / decommissioning > > > Key: HBASE-10367 > URL: https://issues.apache.org/jira/browse/HBASE-10367 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Jerry He > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-10367-master.patch, HBASE-10367-master.patch > > > Right now, we have a weird way of node decommissioning / graceful stop, which > is a graceful_stop.sh bash script, and a region_mover ruby script, and some > draining server support which you have to manually write to a znode > (really!). Also draining servers is only partially supported in LB operations > (LB does take that into account for roundRobin assignment, but not for normal > balance) > See > http://hbase.apache.org/book/node.management.html and HBASE-3071 > I think we should support graceful stop as a first class citizen. Thinking > about it, it seems that the difference between regionserver stop and graceful > stop is that regionserver stop will close the regions, but the master will > only assign them after the znode is deleted. > In the new master design (or even before), if we allow RS to be able to close > regions on its own (without master initiating it), then graceful stop becomes > regular stop. The RS already closes the regions cleanly, and will reject new > region assignments, so that we don't need much of the balancer or draining > server trickery. > This ties into the new master/AM redesign (HBASE-5487), but still deserves > it's own jira. Let's use this to brainstorm on the design. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
[ https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yu Li updated HBASE-18233: -- Attachment: HBASE-18233-branch-1.2.v4.patch > We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock > - > > Key: HBASE-18233 > URL: https://issues.apache.org/jira/browse/HBASE-18233 > Project: HBase > Issue Type: Bug >Affects Versions: 1.2.7 >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7 > > Attachments: HBASE-18233-branch-1.2.patch, > HBASE-18233-branch-1.2.v2.patch, HBASE-18233-branch-1.2.v3.patch, > HBASE-18233-branch-1.2.v4.patch, HBASE-18233-branch-1.2.v4.patch > > > Please refer to the discuss in HBASE-18144 > https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19002) Introduce more examples to show how to intercept normal region operations
Duo Zhang created HBASE-19002: - Summary: Introduce more examples to show how to intercept normal region operations Key: HBASE-19002 URL: https://issues.apache.org/jira/browse/HBASE-19002 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19001) Remove StoreScanner dependency in our own CP related tests
Duo Zhang created HBASE-19001: - Summary: Remove StoreScanner dependency in our own CP related tests Key: HBASE-19001 URL: https://issues.apache.org/jira/browse/HBASE-19001 Project: HBase Issue Type: Sub-task Components: Coprocessors Reporter: Duo Zhang Fix For: 2.0.0-alpha-4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang, Xinglong updated HBASE-18602:
---
Status: Open (was: Patch Available)
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Assignee: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch, HBASE-18602-master-v2.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map correctAssignments(
>Map existingAssignments)
> throws HBaseIOException{
> Map correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang, Xinglong updated HBASE-18602:
---
Status: Patch Available (was: Open)
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Assignee: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch, HBASE-18602-master-v2.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map correctAssignments(
>Map existingAssignments)
> throws HBaseIOException{
> Map correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203001#comment-16203001
]
Hadoop QA commented on HBASE-18505:
---
(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at
https://builds.apache.org/job/PreCommit-HBASE-Build/9087/console in case of
problems.
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-18505.patch, HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16203002#comment-16203002
]
Hadoop QA commented on HBASE-18602:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m
13s{color} | {color:red} Docker failed to build yetus/hbase:5d60123. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18602 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891962/HBASE-18602-master-v2.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9088/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Assignee: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch, HBASE-18602-master-v2.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map correctAssignments(
>Map existingAssignments)
> throws HBaseIOException{
> Map correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated HBASE-18505:
--
Attachment: HBASE-18505.v2.patch
v2: Moved the module narrowing to only unit tests. Realized that if java code
didn't change, it doesn't make sense to run static analysis in the same way
that it could make sense to run unit tests for e.g. pom change.
Still have two extra whitespace changes to test module trigger.
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-18505.patch, HBASE-18505.v2.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202998#comment-16202998
]
Chia-Ping Tsai commented on HBASE-18602:
HBASE-18350 will make the move of region be executed by master. If you have
time, please take a look at HBASE-18350. [~suxingfate] Thanks for this finding.
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Assignee: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch, HBASE-18602-master-v2.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map correctAssignments(
>Map existingAssignments)
> throws HBaseIOException{
> Map correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18233) We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock
[ https://issues.apache.org/jira/browse/HBASE-18233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202996#comment-16202996 ] Yu Li commented on HBASE-18233: --- It seems to me the review has already passed and waiting for commit. Let me retry the patch to see whether it still applies and get this in if no new UT failures. For branches other than branch-1.2, we may need some refactor work, let's check 1.2 patch first. > We shouldn't wait for readlock in doMiniBatchMutation in case of deadlock > - > > Key: HBASE-18233 > URL: https://issues.apache.org/jira/browse/HBASE-18233 > Project: HBase > Issue Type: Bug >Affects Versions: 1.2.7 >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Blocker > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.2.7 > > Attachments: HBASE-18233-branch-1.2.patch, > HBASE-18233-branch-1.2.v2.patch, HBASE-18233-branch-1.2.v3.patch, > HBASE-18233-branch-1.2.v4.patch > > > Please refer to the discuss in HBASE-18144 > https://issues.apache.org/jira/browse/HBASE-18144?focusedCommentId=16051701=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16051701 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202995#comment-16202995
]
Mike Drob commented on HBASE-18505:
---
The patch did what it was supposed to WRT unit tests. I have no idea how the
findbugs test works for root/modules and if I need to do something differently
for that specific case. Does findbugs module not work with multi-module builds?
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-18505.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang, Xinglong updated HBASE-18602:
---
Attachment: HBASE-18602-master-v2.patch
rebased code to latest master
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Assignee: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch, HBASE-18602-master-v2.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map correctAssignments(
>Map existingAssignments)
> throws HBaseIOException{
> Map correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang, Xinglong reassigned HBASE-18602:
--
Assignee: Wang, Xinglong
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Assignee: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch, HBASE-18602-master-v2.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map correctAssignments(
>Map existingAssignments)
> throws HBaseIOException{
> Map correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18990) ServerLoad doesn't override #equals which leads to #equals in ClusterStatus always false
[ https://issues.apache.org/jira/browse/HBASE-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-18990: -- Attachment: HBASE-18990.master.001.patch > ServerLoad doesn't override #equals which leads to #equals in ClusterStatus > always false > > > Key: HBASE-18990 > URL: https://issues.apache.org/jira/browse/HBASE-18990 > Project: HBase > Issue Type: Bug >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-18990.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18990) ServerLoad doesn't override #equals which leads to #equals in ClusterStatus always false
[ https://issues.apache.org/jira/browse/HBASE-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-18990: -- Status: Patch Available (was: Open) > ServerLoad doesn't override #equals which leads to #equals in ClusterStatus > always false > > > Key: HBASE-18990 > URL: https://issues.apache.org/jira/browse/HBASE-18990 > Project: HBase > Issue Type: Bug >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-18990.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18990) ServerLoad doesn't override #equals which leads to #equals in ClusterStatus always false
[ https://issues.apache.org/jira/browse/HBASE-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-18990: -- Attachment: (was: HBASE-18990.master.001.patch) > ServerLoad doesn't override #equals which leads to #equals in ClusterStatus > always false > > > Key: HBASE-18990 > URL: https://issues.apache.org/jira/browse/HBASE-18990 > Project: HBase > Issue Type: Bug >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-18990.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18990) ServerLoad doesn't override #equals which leads to #equals in ClusterStatus always false
[ https://issues.apache.org/jira/browse/HBASE-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-18990: -- Status: Open (was: Patch Available) > ServerLoad doesn't override #equals which leads to #equals in ClusterStatus > always false > > > Key: HBASE-18990 > URL: https://issues.apache.org/jira/browse/HBASE-18990 > Project: HBase > Issue Type: Bug >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-18990.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18624) Added support for clearing BlockCache based on table name
[ https://issues.apache.org/jira/browse/HBASE-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202935#comment-16202935 ] Anoop Sam John commented on HBASE-18624: You mean that would indicate the % cache been cleared? WRT space none of this can give a better corrected value. Because the size depend not just on count of blocks been evicted but each ones size too. In BC any of the evict APIs calculating the size been cleared? Ya that would be the best return if it can say the size. This Admin API can return an Object so that later , if needed, we can add new states easily with out breaking the BC? Just saying as we are having a Public API here/ > Added support for clearing BlockCache based on table name > - > > Key: HBASE-18624 > URL: https://issues.apache.org/jira/browse/HBASE-18624 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0, 1.3.0 >Reporter: Ajay Jadhav >Assignee: Zach York > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-18624.branch-1.001.patch, > HBASE-18624.master.001.patch, HBASE-18624.master.002.patch, > HBASE-18624.master.003.patch > > > Bulk loading the primary HBase cluster triggers a lot of compactions > resulting in archival/ creation > of multiple HFiles. This process will cause a lot of items to become stale in > replica’s BlockCache. > This patch will help users to clear the block cache for a given table by > either using shell or API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202932#comment-16202932 ] Anoop Sam John commented on HBASE-12260: Thats interesting [~appy].. I still have to read this patch but I know what this might be doing. So on the RSS and CPRSS part, the name is the issue or having 2 interfaces [~stack]? If the former, then my 1st approach there was to expose the RSS itself have an extended InternalRSS for our use within core code. Having 2 interfaces with a parent with limited functions (for CP) is fine only IMHO. > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch, HBASE-12260.master.014.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-18998:
---
Fix Version/s: 2.0.0-alpha-4
1.5.0
1.4.0
Patch applies cleanly from branch-2 to branch-1.4
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 1.4.0, 1.5.0, 2.0.0-alpha-4
>
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1650)
> {code}
> Here is code from branch-1.1 :
> {code}
> if (!mutations.isEmpty() && !walSyncSuccessful) {
> LOG.warn("Wal sync failed. Roll back " + mutations.size() +
>
[jira] [Commented] (HBASE-18747) Introduce new example and helper classes to tell CP users how to do filtering on scanners
[
https://issues.apache.org/jira/browse/HBASE-18747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202921#comment-16202921
]
Duo Zhang commented on HBASE-18747:
---
Ping [~stack] [~anoopsamjohn]. This is mainly an example. If no concerns let's
commit it? Then I could start working on the follow on issues.
Thanks.
> Introduce new example and helper classes to tell CP users how to do filtering
> on scanners
> -
>
> Key: HBASE-18747
> URL: https://issues.apache.org/jira/browse/HBASE-18747
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18747.patch
>
>
> Finally we decided that CP users should not have the ability to create
> {{StoreScanner}} or {{StoreFileScanner}}, so it is impossible for them to
> filter out some cells when flush or compaction by simply provide a filter
> when constructing {{StoreScanner}}.
> But I think filtering out some cells is a very important usage for CP users,
> so we need to provide the ability in another way. Theoretically it can be
> done with wrapping an {{InternalScanner}}, but I think we need to give an
> example, or even some helper classes to help CP users.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202909#comment-16202909
]
Hadoop QA commented on HBASE-12260:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
| {color: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 42 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
44s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
42s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
36s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
26s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
40m 22s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
45s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 28m 45s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
22s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
12s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
38s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}118m 50s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestCatalogJanitor |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-12260 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891836/HBASE-12260.master.013.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202898#comment-16202898 ] Appy commented on HBASE-12260: -- After looking at MockNoopHMaster, here's why i think we should rather have a separate internal interface like RegionServerServices. (copy pasting my comment on MockHMaster.java from RB version10) This doesn't look like either a mock or a noop master ([it's probably a 'fake'?|https://stackoverflow.com/questions/346372/whats-the-difference-between-faking-mocking-and-stubbing]) It's not mock because: - HMaster constructor will still initialize a lot of state. If a test call getAM() or getMasterCoprocessorHost(), it'll get something, but if a test calls, getChoreService() or getCoordinatedStateManager(), it'll get null. We only are only nullifying few fns here, rest are still from HMaster. It's like, if a car frame is a mock, and a new car is a proper HMaster object, this one is like http://www.3sgto.org/garage_attachment.php?id=1733. Somethings work, somethings don't. (Note that not calling super() constructor won't help. One will still have to dig into code to figure out what behavior this noop/mock object will exhibit) - It's not easy to maintain either. We cannot enforce that any change to HMaster (or any of it's parent interfaces) will correspondingly add a nullifying function here. Which means that as more fns are added, this will become more and more like real object, and test can start to rely on that, which will be very bad. That doesn't happen when tests do Mockito.mock() by themselves. One, its isolated from concrete classes; Two, test can setup exact behavior with when().then(). - Tests using this will start depending on each other inexplicably in two ways: 1) If a new test comes which wants to mock something, it can't, because previous tests are probably relying on current non-mocked behavior 2) First test to add mocked version of any function will govern what 'mock' means. Does it mean returning null, or does it mean returning empty. That's why, although RSS has an extra internal interface, i like that better since interfaces give better testing platform using mocks. Both ways, we need something extra, either an interface, or a mock class. I am just justifying why former is much better than latter. > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch, HBASE-12260.master.014.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[
https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202886#comment-16202886
]
Hadoop QA commented on HBASE-18355:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 4 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
13s{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
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
12s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
45m 54s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
56s{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:green}+1{color} | {color:green} unit {color} | {color:green} 16m
13s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 77m 0s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18355 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891848/HBASE-18355-master_v002.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit xml compile
findbugs hadoopcheck hbaseanti checkstyle |
| uname | Linux 5a9af88be496 3.13.0-123-generic #172-Ubuntu SMP Mon Jun 26
18:04:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 883c358 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9083/testReport/ |
| modules | C: hbase-mapreduce U: hbase-mapreduce |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9083/console |
| Powered by | Apache Yetus
[jira] [Commented] (HBASE-18967) Backport HBASE-17181 to branch-1.3
[
https://issues.apache.org/jira/browse/HBASE-18967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202888#comment-16202888
]
Hadoop QA commented on HBASE-18967:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
37s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
14s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
28s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
30s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
22s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
18s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
22s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
22s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 21s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
22s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 18m 52s{color}
| {color:red} hbase-thrift in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 65m 26s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce
[jira] [Updated] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18505:
Fix Version/s: 1.1.13
2.0.0-beta-1
1.2.7
1.5.0
1.3.2
1.4.0
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13
>
> Attachments: HBASE-18505.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202876#comment-16202876
]
Sean Busbey commented on HBASE-18505:
-
{quote}
0 findbugs0m 0s Skipped patched modules with no Java source: .
{quote}
This looks wrong. Maybe because the findbugs plugin only looks in the immediate
{{src/main/java}}?
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: HBASE-18505.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18601) Update Htrace to 4.2
[
https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202874#comment-16202874
]
Hadoop QA commented on HBASE-18601:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color: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 7 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
35s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 7m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
2s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 12m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
46s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
19s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
14s{color} | {color:red} hbase-rest in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
34s{color} | {color:red} hbase-spark in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 9m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 9m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 6m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
4s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
2s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
24s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
29s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
37m 58s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 14m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 7m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
28s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
21s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} |
[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2
[
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202861#comment-16202861
]
Hadoop QA commented on HBASE-18350:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
37s{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} 1m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
40s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
30s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
28s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
10s{color} | {color:red} The patch generated 5 new + 13 unchanged - 4 fixed =
18 total (was 17) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
5s{color} | {color:red} The patch generated 6 new + 26 unchanged - 1 fixed = 32
total (was 27) {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
35s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
66m 5s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}135m
23s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 15m 57s{color}
| {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
54s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
41s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}260m 15s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | org.apache.hadoop.hbase.rsgroup.TestRSGroups |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA
[jira] [Commented] (HBASE-18996) Backport HBASE-17703 (TestThriftServerCmdLine is flaky in master branch) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-18996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202848#comment-16202848
]
Hadoop QA commented on HBASE-18996:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color: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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
13s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
25s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
18s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
14s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
19s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
20s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 22s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
20s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 18m 38s{color}
| {color:red} hbase-thrift in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 58m 44s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18996 |
| JIRA Patch URL |
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202843#comment-16202843
]
Hadoop QA commented on HBASE-12260:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} docker {color} | {color:red} 0m
13s{color} | {color:red} Docker failed to build yetus/hbase:5d60123. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-12260 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891855/HBASE-12260.master.014.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9085/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> MasterServices needs a short-back-and-sides; pare-back exposure of internals
> and IA.Private classes
> ---
>
> Key: HBASE-12260
> URL: https://issues.apache.org/jira/browse/HBASE-12260
> Project: HBase
> Issue Type: Sub-task
> Components: master
>Reporter: ryan rawson
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-12260.master.001.patch,
> HBASE-12260.master.002.patch, HBASE-12260.master.003.patch,
> HBASE-12260.master.004.patch, HBASE-12260.master.005.patch,
> HBASE-12260.master.006.patch, HBASE-12260.master.007.patch,
> HBASE-12260.master.008.patch, HBASE-12260.master.009.patch,
> HBASE-12260.master.010.patch, HBASE-12260.master.011.patch,
> HBASE-12260.master.011.patch, HBASE-12260.master.012.patch,
> HBASE-12260.master.013.patch, HBASE-12260.master.014.patch
>
>
> A major issue with MasterServices is the MasterCoprocessorEnvironment exposes
> this class even though MasterServices is tagged with
> @InterfaceAudience.Private
> This means that the entire internals of the HMaster is essentially part of
> the coprocessor API. Many of the classes returned by the MasterServices API
> are highly internal, extremely powerful, and subject to constant change.
> Perhaps a new API to replace MasterServices that is use-case focused, and
> justified based on real world co-processors would suit things better.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202832#comment-16202832 ] stack commented on HBASE-12260: --- .014 minor fixup. This patch can only go in after HBASE-18350 (I'll have to reenable a bunch of disabled RSGroup code). > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch, HBASE-12260.master.014.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12260: -- Attachment: HBASE-12260.master.014.patch > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch, HBASE-12260.master.014.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18967) Backport HBASE-17181 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202814#comment-16202814 ] Peter Somogyi commented on HBASE-18967: --- Retry. Locally I don't see this timeout and on precommit it fails. > Backport HBASE-17181 to branch-1.3 > -- > > Key: HBASE-18967 > URL: https://issues.apache.org/jira/browse/HBASE-18967 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18967.branch-1.3.001.patch, > HBASE-18967.branch-1.3.001.patch, HBASE-18967.branch-1.3.001.patch, > HBASE-18967.branch-1.3.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18967) Backport HBASE-17181 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18967: -- Attachment: HBASE-18967.branch-1.3.001.patch > Backport HBASE-17181 to branch-1.3 > -- > > Key: HBASE-18967 > URL: https://issues.apache.org/jira/browse/HBASE-18967 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18967.branch-1.3.001.patch, > HBASE-18967.branch-1.3.001.patch, HBASE-18967.branch-1.3.001.patch, > HBASE-18967.branch-1.3.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-18355: - Attachment: HBASE-18355-master_v002.patch v2 patch, the jboss jar is actually io.netty. > Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18355 > URL: https://issues.apache.org/jira/browse/HBASE-18355 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Attachments: HBASE-18355-master_v001.patch, > HBASE-18355-master_v002.patch > > > The Proc-V2 AM in HBASE-14614 disabled the following tests: > - Disabled TestExportSnapshot Hangs. > - Disabled TestSecureExportSnapshot > - Disabled TestMobSecureExportSnapshot and TestMobExportSnapshot > This JIRA tracks the work to enable them. If MOB requires more work, we > could split to 2 tickets. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-17369) Add ACL to the new region server drain related API
[ https://issues.apache.org/jira/browse/HBASE-17369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16201381#comment-16201381 ] Jerry He edited comment on HBASE-17369 at 10/12/17 11:18 PM: - The patch on HBASE-10367 has added the ACL. was (Author: jinghe): The patch on HBASe-10367 has added the ACL. > Add ACL to the new region server drain related API > -- > > Key: HBASE-17369 > URL: https://issues.apache.org/jira/browse/HBASE-17369 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Jerry He >Priority: Critical > > Add ACL to the new region server drain related API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18996) Backport HBASE-17703 (TestThriftServerCmdLine is flaky in master branch) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-18996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18996: -- Attachment: HBASE-18996.branch-1.001.patch > Backport HBASE-17703 (TestThriftServerCmdLine is flaky in master branch) to > branch-1 > > > Key: HBASE-18996 > URL: https://issues.apache.org/jira/browse/HBASE-18996 > Project: HBase > Issue Type: Task > Components: Thrift >Affects Versions: 1.3.2, 1.4.1, 1.5.0, 1.2.7, 1.1.13 >Reporter: Peter Somogyi >Assignee: Peter Somogyi > Attachments: HBASE-18996.branch-1.001.patch, > HBASE-18996.branch-1.001.patch > > > During HBASE-18967 backport to branch-1.3 a test failure came up which was > fixed in HBASE-17703. > We need to backport it to branch-1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202778#comment-16202778
]
Hadoop QA commented on HBASE-18998:
---
| (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:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
2s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.4.0/precommit-patchnames for
instructions. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color: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
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
29s{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
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
49s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 29s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 94m
53s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}149m 31s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18998 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891801/18998.v1.txt |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 9de6c6abb3fa 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 883c358 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
[jira] [Comment Edited] (HBASE-10367) RegionServer graceful stop / decommissioning
[ https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202369#comment-16202369 ] Jerry He edited comment on HBASE-10367 at 10/12/17 11:09 PM: - These Admin APIs are only in 2.0 alpha's releases so far. We are still ok to change them, I assume? Good point on passing servers being decommissioned to the coprocessor. I did not think about it. It sounds reasonable. was (Author: jinghe): These Admin APIs are only in 2.0 alpha's releases so far. We are still ok to change them, I assume? Good point on passing servers being decommissioned to the coprocessor. I did not thought about it. It sounds reasonable. > RegionServer graceful stop / decommissioning > > > Key: HBASE-10367 > URL: https://issues.apache.org/jira/browse/HBASE-10367 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Jerry He > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-10367-master-2.patch, HBASE-10367-master.patch, > HBASE-10367-master.patch > > > Right now, we have a weird way of node decommissioning / graceful stop, which > is a graceful_stop.sh bash script, and a region_mover ruby script, and some > draining server support which you have to manually write to a znode > (really!). Also draining servers is only partially supported in LB operations > (LB does take that into account for roundRobin assignment, but not for normal > balance) > See > http://hbase.apache.org/book/node.management.html and HBASE-3071 > I think we should support graceful stop as a first class citizen. Thinking > about it, it seems that the difference between regionserver stop and graceful > stop is that regionserver stop will close the regions, but the master will > only assign them after the znode is deleted. > In the new master design (or even before), if we allow RS to be able to close > regions on its own (without master initiating it), then graceful stop becomes > regular stop. The RS already closes the regions cleanly, and will reject new > region assignments, so that we don't need much of the balancer or draining > server trickery. > This ties into the new master/AM redesign (HBASE-5487), but still deserves > it's own jira. Let's use this to brainstorm on the design. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-10367) RegionServer graceful stop / decommissioning
[ https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jerry He updated HBASE-10367: - Attachment: HBASE-10367-master-2.patch v2. updated the coprocessor hooks. Also added a boolean to the decommission API to tell if to offload the regions from the decommissioned server or not. There is use case where we just want to 'isolate' the server, not offload the regions. > RegionServer graceful stop / decommissioning > > > Key: HBASE-10367 > URL: https://issues.apache.org/jira/browse/HBASE-10367 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Jerry He > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-10367-master-2.patch, HBASE-10367-master.patch, > HBASE-10367-master.patch > > > Right now, we have a weird way of node decommissioning / graceful stop, which > is a graceful_stop.sh bash script, and a region_mover ruby script, and some > draining server support which you have to manually write to a znode > (really!). Also draining servers is only partially supported in LB operations > (LB does take that into account for roundRobin assignment, but not for normal > balance) > See > http://hbase.apache.org/book/node.management.html and HBASE-3071 > I think we should support graceful stop as a first class citizen. Thinking > about it, it seems that the difference between regionserver stop and graceful > stop is that regionserver stop will close the regions, but the master will > only assign them after the znode is deleted. > In the new master design (or even before), if we allow RS to be able to close > regions on its own (without master initiating it), then graceful stop becomes > regular stop. The RS already closes the regions cleanly, and will reject new > region assignments, so that we don't need much of the balancer or draining > server trickery. > This ties into the new master/AM redesign (HBASE-5487), but still deserves > it's own jira. Let's use this to brainstorm on the design. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18624) Added support for clearing BlockCache based on table name
[ https://issues.apache.org/jira/browse/HBASE-18624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202767#comment-16202767 ] Ted Yu commented on HBASE-18624: Somehow review board was not responding. Here is reply for the return value : bq. The callee can know how much cache space gettig cleared. How would user interpret the number of blocks cleared as return value ? Would blocks cleared divided by blockCacheCount be better indicator ? > Added support for clearing BlockCache based on table name > - > > Key: HBASE-18624 > URL: https://issues.apache.org/jira/browse/HBASE-18624 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0, 1.3.0 >Reporter: Ajay Jadhav >Assignee: Zach York > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-18624.branch-1.001.patch, > HBASE-18624.master.001.patch, HBASE-18624.master.002.patch, > HBASE-18624.master.003.patch > > > Bulk loading the primary HBase cluster triggers a lot of compactions > resulting in archival/ creation > of multiple HFiles. This process will cause a lot of items to become stale in > replica’s BlockCache. > This patch will help users to clear the block cache for a given table by > either using shell or API. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202745#comment-16202745 ] stack commented on HBASE-12260: --- On TODOs: * Schedule and wait on flush/compaction ** This is RegionServer-side, not Master-side. Can schedule Flush or Compaction via Admin on Master side but no means for blocking (AsyncAdmin returns a CompletableFuture but it too is just a request; it does not have the future wait on completion of compaction). * Creating system tables (Done via Admin. Testing) ** Only Master process can make system tables (while at it, only Master can write hbase:meta). TODO. Tried but the RpcService is unreliable and we want to check that the request comes from same process, not just same IP. * Review of RSGroups to see what functionality need to add back into MasterServices ** This is blocked on RSGroup work. Will require more exposure I think but already the RSGroup fixup has removed need of our exposing table locks. Thats a big help. * Metrics/by-pass ** TODO: if bypass is selective and we can update metrics even on bypass, then we won't have to let out metrics. So, three follow-ons: only master can make system tables, do we have to expose more functionality for CPs (see what RSGroup needs when done), and do bypass to see if we need to let out metrics or not. > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202749#comment-16202749 ] stack commented on HBASE-12260: --- .013 fix tests (except one I can't figure that comes of our using mocks over HMaster than over RegionServer around the crptic wal splitting engine). Lets see what hadoopqa says. Will look at rb in meantime. I think patch ready to go. Can address the TODOs above in follow-ons. > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202752#comment-16202752
]
Enis Soztutar commented on HBASE-18901:
---
The v4 patch compilation failed for me:
{code}
/usr/src/hbase/hbase-native-client/src/hbase/serde/rpc-serde.cc:32:33: fatal
error: hbase/utils/version.h: No such file or directory
{code}
{{version.h}} is a generated file which is generated from the mvn build, and
gets copied from its original place via bin/copy-version.h. Also the makefile
and buck calls bin/copy-protobuf.sh as well.
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch,
> HBASE-18901.v4.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12260: -- Attachment: HBASE-12260.master.013.patch > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch, > HBASE-12260.master.013.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202759#comment-16202759
]
Enis Soztutar commented on HBASE-18901:
---
After running bin/copy-version.sh, I still get the build error in the docker
env:
{code}
libhbaseclient.a(ClusterId.pb.cc.o):(.rodata._ZTVN5hbase2pb9ClusterIdE[_ZTVN5hbase2pb9ClusterIdE]+0x20):
undefined reference to `google::protobuf::Message::GetTypeName[abi:cxx11]()
const'
libhbaseclient.a(ClusterId.pb.cc.o):(.rodata._ZTVN5hbase2pb9ClusterIdE[_ZTVN5hbase2pb9ClusterIdE]+0x58):
undefined reference to
`google::protobuf::Message::InitializationErrorString[abi:cxx11]() const'
collect2: error: ld returned 1 exit status
CMakeFiles/zk-deserializer-test.dir/build.make:139: recipe for target
'zk-deserializer-test' failed
make[2]: *** [zk-deserializer-test] Error 1
CMakeFiles/Makefile2:68: recipe for target
'CMakeFiles/zk-deserializer-test.dir/all' failed
make[1]: *** [CMakeFiles/zk-deserializer-test.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
{code}
do you guys see the same?
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch,
> HBASE-18901.v4.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-10367) RegionServer graceful stop / decommissioning
[ https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202755#comment-16202755 ] stack commented on HBASE-10367: --- Yes. You can change unreleased APIs [~jerryhe]. > RegionServer graceful stop / decommissioning > > > Key: HBASE-10367 > URL: https://issues.apache.org/jira/browse/HBASE-10367 > Project: HBase > Issue Type: Improvement >Reporter: Enis Soztutar >Assignee: Jerry He > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-10367-master.patch, HBASE-10367-master.patch > > > Right now, we have a weird way of node decommissioning / graceful stop, which > is a graceful_stop.sh bash script, and a region_mover ruby script, and some > draining server support which you have to manually write to a znode > (really!). Also draining servers is only partially supported in LB operations > (LB does take that into account for roundRobin assignment, but not for normal > balance) > See > http://hbase.apache.org/book/node.management.html and HBASE-3071 > I think we should support graceful stop as a first class citizen. Thinking > about it, it seems that the difference between regionserver stop and graceful > stop is that regionserver stop will close the regions, but the master will > only assign them after the znode is deleted. > In the new master design (or even before), if we allow RS to be able to close > regions on its own (without master initiating it), then graceful stop becomes > regular stop. The RS already closes the regions cleanly, and will reject new > region assignments, so that we don't need much of the balancer or draining > server trickery. > This ties into the new master/AM redesign (HBASE-5487), but still deserves > it's own jira. Let's use this to brainstorm on the design. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-19000) Group multiple block cache clear requests per server
Ted Yu created HBASE-19000: -- Summary: Group multiple block cache clear requests per server Key: HBASE-19000 URL: https://issues.apache.org/jira/browse/HBASE-19000 Project: HBase Issue Type: Sub-task Reporter: Ted Yu During the review of HBASE-18624, I brought up the following: There would be multiple regions on the same server whose block cache is to be cleared. Multiple block cache clear requests should be grouped per server to reduce the number of RPC calls. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10367) RegionServer graceful stop / decommissioning
[
https://issues.apache.org/jira/browse/HBASE-10367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202741#comment-16202741
]
Hadoop QA commented on HBASE-10367:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{color} | {color:blue} Docker mode activated. {color} |
| {color: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 5 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
31s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
28s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 5m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 5m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
54s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
5s{color} | {color:red} The patch generated 1 new + 40 unchanged - 0 fixed = 41
total (was 40) {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
1s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
44s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
42m 32s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
3m 25s{color} | {color:green} the patch passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
43s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
30s{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 2m
42s{color} | {color:red} root generated 1 new + 25 unchanged - 0 fixed = 26
total (was 25) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
28s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color}
[jira] [Updated] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()
[ https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-18960: - Attachment: hbase-18960.master.007.patch Changes per latest review comments. Added UT for replay batch with multiple nonces code path and fixed a bug with mvcc complete() and advanceTo() for replay batch. > A few bug fixes and minor improvements around batchMutate() > --- > > Key: HBASE-18960 > URL: https://issues.apache.org/jira/browse/HBASE-18960 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 2.0.0-alpha-3 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18960.master.001.patch, > hbase-18960.master.002.patch, hbase-18960.master.003.patch, > hbase-18960.master.004.patch, hbase-18960.master.005.patch, > hbase-18960.master.005.patch, hbase-18960.master.006.patch, > hbase-18960.master.007.patch > > > Batch validation and preparation can be done before we start iterating over > batch operations for writes. observedExceptions, familyCellMaps and > durability can be stored in BatchOperation as they are batch wide. For all > operations, done by preBatchMutate() CP hook, operation status needs to be > SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202728#comment-16202728
]
Enis Soztutar commented on HBASE-18901:
---
Also the naming should be {{libhbaseclient}}, or {{libHBaseClient}}? I guess,
libhbaseclient is more in-line with naming conventions under /usr/local/lib. I
like it.
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch,
> HBASE-18901.v4.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g
[
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202704#comment-16202704
]
Hadoop QA commented on HBASE-13346:
---
| (/) *{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: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 18 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
57s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
26s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
57s{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
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 37s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
35s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 92m
15s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
11s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
56s{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
54s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}179m 11s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-13346 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891786/HBASE-13346.master.006.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 41ce28574367 3.13.0-129-generic
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202695#comment-16202695 ] marco polo commented on HBASE-18901: [~enis] That line should have been removed. I removed it in my test VM but not the one from which I pushed. That's an error. * The prior structure was src/hbase/X, which means you need to specify specific files for test. Maintaining that structure is a good idea. We do that on Apache MiNiFi, and I think that's a good idea to do here. * I like the idea of moving the load-client and simplie-client to hbase/X * I'll take a look at the JNI dependency. I believe that is something we can move to the test targets. It should be easy to resolve. I'll take a look a little later when I have some time. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18901: --- Attachment: HBASE-18901.v4.HBASE-14850.patch v4 removes the BUCK files and now unnecessary Makefiles. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch, > HBASE-18901.v4.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202686#comment-16202686
]
Josh Elser commented on HBASE-18901:
bq. Shouldn't we remove the current Makefile in this patch as well? Cmake will
create the makefile, no?
Yup, my bad. Meant to do that, and apparently forgot to do the {{git rm}}
bq. In HBASE-18727, we explicitly removed the JNI dependency from the main
libHBaseClient build. That is why the headers under test-util stayed in the src
directory instead of the include dir. Are we requiring libjni with this build?
I do know that CMake would fail for me with only a JRE installed about JNI
stuff. This might be an unintended regression.
bq. Remove this line, instead of commenting out?
Let me nuke that too.
bq. Get rid of buck based build, and all of the BUCK files, etc.
And this too.
Will leave the other ones to Marc to give some feedback on at his leisure.
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202679#comment-16202679
]
Enis Soztutar commented on HBASE-18901:
---
Great, this is a good start.
I think we should stick with CMake going forward, since it seems to be the most
popular tool used by most of our dependencies, Hadoop, and in the cpp
community. We should get rid of current Makefile and the buck based build. No
need to support both.
A couple of questions for the patch:
- Shouldn't we remove the current Makefile in this patch as well? Cmake will
create the makefile, no?
- All of the tests go under test/ rather than being modularized. Is that
intentional? Is there a way to keep the structure as {{src/test/client}},
{{src/test/connection}}, etc?
- I would say simple-client and load-client are useful for benchmarking and
testing. Maybe we should move them under {{src/hbase/exe/}}, {{src/hbase/bin}}
or maybe {{src/hbase/app}}.
{code}
rename hbase-native-client/src/hbase/{client => examples}/load-client.cc (100%)
rename hbase-native-client/src/hbase/{client => examples}/simple-client.cc
(100%)
{code}
- In HBASE-18727, we explicitly removed the JNI dependency from the main
libHBaseClient build. That is why the headers under test-util stayed in the src
directory instead of the include dir. Are we requiring libjni with this build?
{code}
diff --git a/hbase-native-client/src/hbase/test-util/test-util.h
b/hbase-native-client/include/hbase/test-util/test-util.h
{code}
- Remove this line, instead of commenting out?
{code}
-#include
+//#include
{code}
Follow up items that we should do after this patch:
- Get rid of buck based build, and all of the BUCK files, etc.
- Hook up cmake with the general mvn build by providing a pom.xml in the
module. calling mvn compile or test with {{-Pnative}} should kick in the native
build with cmake. See Hadoop's integration for an example.
-
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18999) Put in hbase shell cannot do multiple columns
Mike Drob created HBASE-18999:
-
Summary: Put in hbase shell cannot do multiple columns
Key: HBASE-18999
URL: https://issues.apache.org/jira/browse/HBASE-18999
Project: HBase
Issue Type: Improvement
Components: shell
Affects Versions: 1.0.0, 2.0.0
Reporter: Mike Drob
A {{Put}} can carry multiple cells, but doing so in the shell is very difficult
to construct. We should make this easier.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18183) Region interface cleanup for CP expose
[ https://issues.apache.org/jira/browse/HBASE-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202637#comment-16202637 ] Andrew Purtell commented on HBASE-18183: bq. Exposing metric we dont have. Unless some one ask for HBase metric within CP, lets not give? Metrics are a public facing interface and as long as we are allowing bypass semantics then CPs need to be able to update them as needed to simulate what core would have done. Fine to make it a subtask. Also fine to defer it until someone asks or is motivated to h > Region interface cleanup for CP expose > -- > > Key: HBASE-18183 > URL: https://issues.apache.org/jira/browse/HBASE-18183 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18183.patch, HBASE-18183_V2.patch, > HBASE-18183_V3.patch, HBASE-18183_V4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18183) Region interface cleanup for CP expose
[ https://issues.apache.org/jira/browse/HBASE-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202637#comment-16202637 ] Andrew Purtell edited comment on HBASE-18183 at 10/12/17 9:18 PM: -- bq. Exposing metric we dont have. Unless some one ask for HBase metric within CP, lets not give? Metrics are a public facing interface and as long as we are allowing bypass semantics then CPs need to be able to update them as needed to simulate what core would have done. Fine to make it a subtask. Also fine to defer it until someone asks or is motivated to make a patch. was (Author: apurtell): bq. Exposing metric we dont have. Unless some one ask for HBase metric within CP, lets not give? Metrics are a public facing interface and as long as we are allowing bypass semantics then CPs need to be able to update them as needed to simulate what core would have done. Fine to make it a subtask. Also fine to defer it until someone asks or is motivated to h > Region interface cleanup for CP expose > -- > > Key: HBASE-18183 > URL: https://issues.apache.org/jira/browse/HBASE-18183 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18183.patch, HBASE-18183_V2.patch, > HBASE-18183_V3.patch, HBASE-18183_V4.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202633#comment-16202633
]
Hadoop QA commented on HBASE-18505:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
27s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
4s{color} | {color:blue} Shelldocs was not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
39s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
9s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
48s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
19s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
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}
38m 24s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}169m
17s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
28s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
|
[jira] [Commented] (HBASE-18982) Metrics are lost when Metrics-Region-Source object is de-registered from Metrics-Aggregate-Region-Source object.
[ https://issues.apache.org/jira/browse/HBASE-18982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202632#comment-16202632 ] Andrew Purtell commented on HBASE-18982: This seems like a good suggestion [~Misraji]. Are you thinking about contributing a patch? > Metrics are lost when Metrics-Region-Source object is de-registered from > Metrics-Aggregate-Region-Source object. > > > Key: HBASE-18982 > URL: https://issues.apache.org/jira/browse/HBASE-18982 > Project: HBase > Issue Type: Bug > Components: Coprocessors, metrics >Reporter: Ashish Misra >Priority: Minor > > The Metrics-Region-Source class maintains metrics for a given region. > The Metrics-Region-Aggregate-Source class allows register/deregister of > objects of type Metric-Region-Source. The get-Metrics method on > Metrics-Region-Source-Aggregate class, gets metrics from all the > Metrics-Region-Source objects registered with it. > The Metrics-Region-Source object is deregistered when the region is closed. > When a Metrics-Region-Source object is deregistered, its directly removed > from the set maintained by Metrics-Region-Aggregate-Source object. In such a > case, the final metrics of Metrics-Region-Source object are lost. These > metrics must be logged one last time before the Metrics-Region-Source object > is removed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18997) Remove the redundant methods in RegionInfo
[
https://issues.apache.org/jira/browse/HBASE-18997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202628#comment-16202628
]
Hadoop QA commented on HBASE-18997:
---
| (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: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 11 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
34s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
19s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
42s{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
15s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
42m 11s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
39s{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:green}+1{color} | {color:green} unit {color} | {color:green} 2m
40s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}112m 7s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
17s{color} | {color:green} hbase-mapreduce in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
49s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}197m 39s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestPriorityRpc |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18997 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891758/HBASE-18997.v0.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 368fc035b90e 3.13.0-123-generic #172-Ubuntu SMP Mon Jun 26
18:04:35 UTC 2017 x86_64 x86_64 x86_64
[jira] [Updated] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated HBASE-18901: --- Attachment: HBASE-18901.v3.HBASE-14850.patch v3 fixes the trailing whitespace, adds the new stuff to .gitignore, and removes the old Makefile. I've tested this on an Ubuntu16 docker image https://github.com/joshelser/hbase-native-testing. My half-broken application there, as well as Enis' not-broken examples :) [~enis], [~tedyu], I think this one is ready to go, what do you both think? > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch, HBASE-18901.v3.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18966) In-memory compaction/merge should update its time range
[
https://issues.apache.org/jira/browse/HBASE-18966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202611#comment-16202611
]
Hadoop QA commented on HBASE-18966:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
38s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
25s{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
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
18s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
42m 4s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
34s{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:green}+1{color} | {color:green} unit {color} | {color:green} 2m
39s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}112m 16s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
46s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}183m 21s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.regionserver.TestCompactingToCellFlatMapMemStore |
| | hadoop.hbase.regionserver.TestCompactingMemStore |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18966 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891756/HBASE-18966.v2.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 6e55e4e0bae1 3.13.0-123-generic #172-Ubuntu SMP Mon Jun 26
18:04:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202594#comment-16202594 ] marco polo commented on HBASE-18901: [~elserj] I agree with everything above. I most certainly do not object! Thanks! > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202586#comment-16202586 ] Josh Elser commented on HBASE-18901: Let me just get a v3 together for Marc. He's already gone way above and beyond my wildest dreams in helping out here. Please object if you want to finish it yourself, Marc. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[
https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202583#comment-16202583
]
Josh Elser commented on HBASE-18901:
Disclaimer: I've been working closely with [~phrocker] on this one this week.
* {{git-am}} complains about squashing some whitespace (I expect the same from
QA) -- Can fix on commit
* We should add the CMake temporary files to .gitignore
* Ditto to the executables built and dropped in hbase-native-client/
* Should we remove the old Makefile? (and also add that to .gitignore?)
> Support build with CMake
>
>
> Key: HBASE-18901
> URL: https://issues.apache.org/jira/browse/HBASE-18901
> Project: HBase
> Issue Type: Sub-task
>Reporter: Josh Elser
>Assignee: marco polo
> Labels: C++
> Fix For: HBASE-14850
>
> Attachments: HBASE-18901.v1.HBASE-14850.patch,
> HBASE-18901.v2.HBASE-14850.patch
>
>
> I've co-opted some help from folks in trying to support CMake as the build
> tool instead of Buck.
> They have something working, but need to consolidate the patch. Filing an
> issue for them to put a patch on.
> FYI [~enis], [~tedyu]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-18998:
--
Assignee: Ted Yu
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1650)
> {code}
> Here is code from branch-1.1 :
> {code}
> if (!mutations.isEmpty() && !walSyncSuccessful) {
> LOG.warn("Wal sync failed. Roll back " + mutations.size() +
> " memstore keyvalues for row(s):" + StringUtils.byteToHexString(
> processor.getRowsToLock().iterator().next()) + "...");
> {code}
> The
[jira] [Updated] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-18998:
---
Attachment: 18998.v1.txt
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1650)
> {code}
> Here is code from branch-1.1 :
> {code}
> if (!mutations.isEmpty() && !walSyncSuccessful) {
> LOG.warn("Wal sync failed. Roll back " + mutations.size() +
> " memstore keyvalues for row(s):" + StringUtils.byteToHexString(
> processor.getRowsToLock().iterator().next()) + "...");
> {code}
> The assumption that
[jira] [Updated] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-18998:
---
Status: Patch Available (was: Open)
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 18998.v1.txt
>
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1650)
> {code}
> Here is code from branch-1.1 :
> {code}
> if (!mutations.isEmpty() && !walSyncSuccessful) {
> LOG.warn("Wal sync failed. Roll back " + mutations.size() +
> " memstore keyvalues for row(s):" + StringUtils.byteToHexString(
> processor.getRowsToLock().iterator().next()) + "...");
>
[jira] [Commented] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
[
https://issues.apache.org/jira/browse/HBASE-18998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202576#comment-16202576
]
Josh Elser commented on HBASE-18998:
This is a bit strange looking (why, you might ask, is Phoenix calling
{{mutateRowsWithLocks}} without specifying any rows to lock?).
The Phoenix CP MetaDataEndpointImpl has already grabbed the necessary rows to
lock that it needs. So here, when it's actually submitting the mutations that
its built, it knows that it has already exclusively locked that row (necessary
to prevent concurrent, conflicting DDL operations) and it provides no row
locks. Pretty simple fix from our side that just looks a little weird.
> processor.getRowsToLock() always assumes there is some row being locked
> ---
>
> Key: HBASE-18998
> URL: https://issues.apache.org/jira/browse/HBASE-18998
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>
> During testing, we observed the following exception:
> {code}
> 2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
> testTable;
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
> ipc.CoprocessorRpcChannel: Call failed on IOException
> 2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
> org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
> 2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
> java.util.NoSuchElementException
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> java.util.Collections$EmptyIterator.next(Collections.java:4189)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
> 2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
> run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
> 2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
>
[jira] [Created] (HBASE-18998) processor.getRowsToLock() always assumes there is some row being locked
Ted Yu created HBASE-18998:
--
Summary: processor.getRowsToLock() always assumes there is some
row being locked
Key: HBASE-18998
URL: https://issues.apache.org/jira/browse/HBASE-18998
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
During testing, we observed the following exception:
{code}
2017-10-12 02:52:26,683|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|1/1 DROP TABLE
testTable;
2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|17/10/12 02:52:30 WARN
ipc.CoprocessorRpcChannel: Call failed on IOException
2017-10-12 02:52:30,320|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|org.apache.hadoop.hbase.DoNotRetryIOException:
org.apache.hadoop.hbase.DoNotRetryIOException: TESTTABLE: null
2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.phoenix.util.ServerUtil.createIOException(ServerUtil.java:93)
2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1671)
2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:14347)
2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7849)
2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1980)
2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1962)
2017-10-12 02:52:30,321|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32389)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2150)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:112)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:187)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:167)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|Caused by:
java.util.NoSuchElementException
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
java.util.Collections$EmptyIterator.next(Collections.java:4189)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.regionserver.HRegion.processRowsWithLocks(HRegion.java:7137)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:6980)
2017-10-12 02:52:30,322|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.phoenix.coprocessor.MetaDataEndpointImpl.mutateRowsWithLocks(MetaDataEndpointImpl.java:1966)
2017-10-12 02:52:30,323|INFO|MainThread|machine.py:164 -
run()||GUID=f4cd2a25-3040-41cc-b423-9ec7990048f4|at
org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:1650)
{code}
Here is code from branch-1.1 :
{code}
if (!mutations.isEmpty() && !walSyncSuccessful) {
LOG.warn("Wal sync failed. Roll back " + mutations.size() +
" memstore keyvalues for row(s):" + StringUtils.byteToHexString(
processor.getRowsToLock().iterator().next()) + "...");
{code}
The assumption that processor.getRowsToLock().iterator() would always be
non-empty was wrong.
In other branches, taking the iterator seems to have the same issue.
Thanks to [~elserj] who spotted this issue.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[
https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202559#comment-16202559
]
Hadoop QA commented on HBASE-16338:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
5s{color} | {color:blue} Shelldocs was 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 17 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
25s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
4s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-resource-bundle hbase-shaded hbase-shaded/hbase-shaded-mapreduce .
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
55s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
19s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
14s{color} | {color:red} hbase-rest in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
35s{color} | {color:red} hbase-spark in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
4s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
1s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
13s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
28s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 10s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-resource-bundle hbase-shaded hbase-shaded/hbase-shaded-mapreduce .
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} |
[jira] [Commented] (HBASE-18805) Unify Admin and AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-18805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202543#comment-16202543 ] Appy commented on HBASE-18805: -- With two admins, which are supposed to be in sync, but no way to ensure that invariant, i won't be surprised if things slipover over years and we have to do another big unification in 3.0. With so many things that can vary - number and types of functions, functions' names, parameter types, return types, etc - i think it'll be best if we can add a test to ensure the invariant. What do you say [~zghaobac]? How about a test which uses reflection on both interfaces to make sure that things match up? > Unify Admin and AsyncAdmin > -- > > Key: HBASE-18805 > URL: https://issues.apache.org/jira/browse/HBASE-18805 > Project: HBase > Issue Type: Umbrella >Reporter: Balazs Meszaros > Fix For: 2.0.0-beta-1 > > > Admin and AsyncAdmin differ some places: > - some methods missing from AsyncAdmin (e.g. methods with String regex), > - some methods have different names (listTables vs listTableDescriptors), > - some method parameters are different (e.g. AsyncAdmin has Optional<> > parameters), > - AsyncAdmin returns Lists instead of arrays (e.g. listTableNames), > - unify Javadoc comments, > - ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18991) Remove RegionMergeRequest
[
https://issues.apache.org/jira/browse/HBASE-18991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202541#comment-16202541
]
Hudson commented on HBASE-18991:
FAILURE: Integrated in Jenkins build HBase-2.0 #674 (See
[https://builds.apache.org/job/HBase-2.0/674/])
HBASE-18991 Removed RegionMergeRequest (chia7712: rev
3cf3dfb65b7d8c2488461da949d0ee48b66295f5)
* (delete)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionMergeRequest.java
> Remove RegionMergeRequest
> -
>
> Key: HBASE-18991
> URL: https://issues.apache.org/jira/browse/HBASE-18991
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Jan Hentschel
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18991.master.001.patch
>
>
> {code}
> /**
> * Handles processing region merges. Put in a queue, owned by HRegionServer.
> */
> // TODO:UNUSED: REMOVE!!!
> @InterfaceAudience.Private
> class RegionMergeRequest implements Runnable {
> {code}
> HBASE-14614 has discharged {{RegionMergeRequest}} from duty.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18992) Comparators passed to the Memstore's flattened segments seems to be wrong
[ https://issues.apache.org/jira/browse/HBASE-18992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202542#comment-16202542 ] Hudson commented on HBASE-18992: FAILURE: Integrated in Jenkins build HBase-2.0 #674 (See [https://builds.apache.org/job/HBase-2.0/674/]) HBASE-18992 Comparators passed to the Memstore's flattened segments (ramkrishna: rev 5a26243a8a605c1f5acb5e25cf61751405eb9a33) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CellChunkImmutableSegment.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CellArrayImmutableSegment.java > Comparators passed to the Memstore's flattened segments seems to be wrong > - > > Key: HBASE-18992 > URL: https://issues.apache.org/jira/browse/HBASE-18992 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1, 2.0.0-alpha-4 > > Attachments: HBASE-18992.patch > > > While doing HBASE-18945 found that the comparators passed to the > CellChunkImmutableSegment and CellArrayImmutableSegment are sometimes wrong. > We pass the comparator that we got from the Store but when doing > reinitializeCellSet we always use CellComparator.COMPARATOR. > From code I don think we are stopping the META region to also go through > CompactingMemstore. If we do that then this JIRA is invalid. But considering > that is not the case we should fix it and pass the right comparator. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18350) RSGroups are broken under AMv2
[ https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18350: -- Attachment: HBASE-18350.master.004.patch > RSGroups are broken under AMv2 > -- > > Key: HBASE-18350 > URL: https://issues.apache.org/jira/browse/HBASE-18350 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: Balazs Meszaros >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18350.master.001.patch, > HBASE-18350.master.002.patch, HBASE-18350.master.003.patch, > HBASE-18350.master.004.patch, HBASE-18350.master.004.patch > > > The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614: > - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what > offline is. > - Disabled/Ignore TestRSGroups. > This JIRA tracks the work to enable them (or remove/modify if not applicable). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g
[
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated HBASE-13346:
-
Status: Patch Available (was: In Progress)
> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
> Issue Type: Bug
> Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch,
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch,
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch,
> HBASE-13346.master.005.patch, HBASE-13346.master.006.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference
> mixed up all over the place, I recommend cleaning this up once and for all.
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or
> parameter name.
> This includes deprecating and renaming filters too, for example
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}}
> as it does _not_ just return the key, but the entire cell. It should be
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs
> {{Column}} in our naming. The latter two are the only ones going forward with
> the public API, and are used synonymous. We should carefully check which is
> better suited (is it really a specific cell, or the newest cell, aka the
> newest column value) and settle on a naming schema.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g
[
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated HBASE-13346:
-
Attachment: HBASE-13346.master.006.patch
> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
> Issue Type: Bug
> Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch,
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch,
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch,
> HBASE-13346.master.005.patch, HBASE-13346.master.006.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference
> mixed up all over the place, I recommend cleaning this up once and for all.
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or
> parameter name.
> This includes deprecating and renaming filters too, for example
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}}
> as it does _not_ just return the key, but the entire cell. It should be
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs
> {{Column}} in our naming. The latter two are the only ones going forward with
> the public API, and are used synonymous. We should carefully check which is
> better suited (is it really a specific cell, or the newest cell, aka the
> newest column value) and settle on a naming schema.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[
https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202463#comment-16202463
]
huaxiang sun commented on HBASE-18355:
--
I run the following with the master. This is what I run into.
{code}
---
Test set: org.apache.hadoop.hbase.snapshot.TestExportSnapshot
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 11.963 sec <<<
FAILURE! - in org.apache.hadoop.hbase.snapshot.TestExportSnapshot
org.apache.hadoop.hbase.snapshot.TestExportSnapshot Time elapsed: 11.962 sec
<<< ERROR!
java.lang.NoClassDefFoundError: org/jboss/netty/channel/group/ChannelGroup
at
org.apache.hadoop.hbase.snapshot.TestExportSnapshot.setUpBeforeClass(TestExportSnapshot.java:102)
Caused by: java.lang.ClassNotFoundException:
org.jboss.netty.channel.group.ChannelGroup
at
org.apache.hadoop.hbase.snapshot.TestExportSnapshot.setUpBeforeClass(TestExportSnapshot.java:102)
{code}
> Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
>
>
> Key: HBASE-18355
> URL: https://issues.apache.org/jira/browse/HBASE-18355
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 2.0.0-alpha-1
>Reporter: Stephen Yuan Jiang
>Assignee: huaxiang sun
> Attachments: HBASE-18355-master_v001.patch
>
>
> The Proc-V2 AM in HBASE-14614 disabled the following tests:
> - Disabled TestExportSnapshot Hangs.
> - Disabled TestSecureExportSnapshot
> - Disabled TestMobSecureExportSnapshot and TestMobExportSnapshot
> This JIRA tracks the work to enable them. If MOB requires more work, we
> could split to 2 tickets.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18912) Update Admin methods to return Lists instead of arrays
[ https://issues.apache.org/jira/browse/HBASE-18912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202456#comment-16202456 ] Peter Somogyi commented on HBASE-18912: --- I'm looking into HBASE-18978 and found this issue. There we have boolean[] existsAll(List gets) and Result[] get(List gets) are similar to this. Should we do the same there? > Update Admin methods to return Lists instead of arrays > -- > > Key: HBASE-18912 > URL: https://issues.apache.org/jira/browse/HBASE-18912 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18991) Remove RegionMergeRequest
[
https://issues.apache.org/jira/browse/HBASE-18991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202408#comment-16202408
]
Hudson commented on HBASE-18991:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3875 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3875/])
HBASE-18991 Removed RegionMergeRequest (chia7712: rev
138a7392e305d61120242bcdcb333b44828b)
* (delete)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionMergeRequest.java
> Remove RegionMergeRequest
> -
>
> Key: HBASE-18991
> URL: https://issues.apache.org/jira/browse/HBASE-18991
> Project: HBase
> Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Jan Hentschel
>Priority: Trivial
> Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-18991.master.001.patch
>
>
> {code}
> /**
> * Handles processing region merges. Put in a queue, owned by HRegionServer.
> */
> // TODO:UNUSED: REMOVE!!!
> @InterfaceAudience.Private
> class RegionMergeRequest implements Runnable {
> {code}
> HBASE-14614 has discharged {{RegionMergeRequest}} from duty.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18667) Disable error-prone for hbase-protocol-shaded
[ https://issues.apache.org/jira/browse/HBASE-18667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202410#comment-16202410 ] Hudson commented on HBASE-18667: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3875 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3875/]) HBASE-18667 Add @Generated to protobuf classes (mdrob: rev 883c3584b8436e2a541eda357e6eb480a61de6b4) * (edit) hbase-protocol/pom.xml * (edit) hbase-protocol-shaded/pom.xml > Disable error-prone for hbase-protocol-shaded > - > > Key: HBASE-18667 > URL: https://issues.apache.org/jira/browse/HBASE-18667 > Project: HBase > Issue Type: Sub-task > Components: build >Reporter: Mike Drob >Assignee: Mike Drob > Fix For: 3.0.0 > > Attachments: HBASE-18667.patch > > > This is all generated code that we shouldn't be running extra analysis on > because it adds a lot of noise to the build, and also takes a very long time > (15 minutes on my machine). Let's make it fast and simple. > Even when we run with error-prone enabled for the rest of the build, it > should not apply here. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18992) Comparators passed to the Memstore's flattened segments seems to be wrong
[ https://issues.apache.org/jira/browse/HBASE-18992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202409#comment-16202409 ] Hudson commented on HBASE-18992: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3875 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3875/]) HBASE-18992 Comparators passed to the Memstore's flattened segments (ramkrishna: rev e7b4f6046a5b672118fd60bf2640968b3ab89a38) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CellArrayImmutableSegment.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CellChunkImmutableSegment.java > Comparators passed to the Memstore's flattened segments seems to be wrong > - > > Key: HBASE-18992 > URL: https://issues.apache.org/jira/browse/HBASE-18992 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1, 2.0.0-alpha-4 > > Attachments: HBASE-18992.patch > > > While doing HBASE-18945 found that the comparators passed to the > CellChunkImmutableSegment and CellArrayImmutableSegment are sometimes wrong. > We pass the comparator that we got from the Store but when doing > reinitializeCellSet we always use CellComparator.COMPARATOR. > From code I don think we are stopping the META region to also go through > CompactingMemstore. If we do that then this JIRA is invalid. But considering > that is not the case we should fix it and pass the right comparator. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202398#comment-16202398
]
Chia-Ping Tsai commented on HBASE-18602:
bq. In the same way, the unassign in FavoredStochasticBalancer#balanceCluster
is not necessary. And meanwhile in most of load balancer, we only decide how to
move the regions without doing the real move actions, whereas in
FavoredStochasticBalancer#balanceCluster we do the real move actions.
You are right. Applying your idea, the
{{FavoredStochasticBalancer#testMisplacedRegions}} pass now. Mind taking a look
at HBASE-18349?
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map correctAssignments(
>Map existingAssignments)
> throws HBaseIOException{
> Map correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18355) Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614
[ https://issues.apache.org/jira/browse/HBASE-18355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202392#comment-16202392 ] Ted Yu commented on HBASE-18355: I ran the following test against hadoop-3 beta1 (without change to pom): Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 808.336 sec - in org.apache.hadoop.hbase.snapshot.TestExportSnapshot > Enable export snapshot tests that were disabled by Proc-V2 AM in HBASE-14614 > > > Key: HBASE-18355 > URL: https://issues.apache.org/jira/browse/HBASE-18355 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: huaxiang sun > Attachments: HBASE-18355-master_v001.patch > > > The Proc-V2 AM in HBASE-14614 disabled the following tests: > - Disabled TestExportSnapshot Hangs. > - Disabled TestSecureExportSnapshot > - Disabled TestMobSecureExportSnapshot and TestMobExportSnapshot > This JIRA tracks the work to enable them. If MOB requires more work, we > could split to 2 tickets. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2
[ https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202388#comment-16202388 ] Balazs Meszaros commented on HBASE-18350: - These tests are enabled and pass on my machine. > RSGroups are broken under AMv2 > -- > > Key: HBASE-18350 > URL: https://issues.apache.org/jira/browse/HBASE-18350 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: Balazs Meszaros >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18350.master.001.patch, > HBASE-18350.master.002.patch, HBASE-18350.master.003.patch, > HBASE-18350.master.004.patch > > > The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614: > - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what > offline is. > - Disabled/Ignore TestRSGroups. > This JIRA tracks the work to enable them (or remove/modify if not applicable). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18505) Our build/yetus personality will run tests on individual modules and then on all (i.e. 'root'). Should do one or other
[
https://issues.apache.org/jira/browse/HBASE-18505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202384#comment-16202384
]
Mike Drob commented on HBASE-18505:
---
I needed a change to trigger the module inclusion for yetus. On commit, I can
drop all changes that are not part of hbase-personality.
> Our build/yetus personality will run tests on individual modules and then on
> all (i.e. 'root'). Should do one or other
> --
>
> Key: HBASE-18505
> URL: https://issues.apache.org/jira/browse/HBASE-18505
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: stack
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: HBASE-18505.patch
>
>
> In runs on end of HBASE-17056, a patch that touches all modules, [~busbey]
> noticed that we were doing unit suite twice... Once for each individual
> module and then again for all/root because patch had root changes in it. We
> shouldn't do all if we are doing 'root' as per [~busbey]
> Here is tail of console output:
> {code}
>
> 10:50:30 cd /testptch/hbase/hbase-spark
> 10:50:30 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-hbase-spark.txt 2>&1
> 10:55:35 Elapsed: 5m 14s
> 10:55:45 cd /testptch/hbase
> 10:55:45 mvn -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.procedure.TestProcedureAdmin.java,**/master.assignment.TestMergeTableRegionsProcedure.java,**/quotas.TestSnapshotQuotaObserverChore.java,**/quotas.TestQuotaThrottle.java,**/client.TestReplicasClient.java,**/client.locking.TestEntityLocks.java,**/security.visibility.TestVisibilityLabelsReplication.java,**/client.TestShell.java,**/master.assignment.TestAssignmentManager.java,**/replication.TestMultiSlaveReplication.java,**/coprocessor.TestRegionObserverInterface.java,**/master.balancer.TestDefaultLoadBalancer.java,**/client.TestReplicaWithCluster.java,**/io.hfile.TestLruBlockCache.java,**/master.balancer.TestFavoredStochasticLoadBalancer.java,**/regionserver.wal.TestAsyncLogRolling.java,**/master.balancer.TestStochasticLoadBalancer.java,**/client.TestMultiParallel.java,**/replication.TestReplicationWithTags.java,**/security.access.TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestReplicator.java,**/master.assignment.TestAssignmentOnRSCrash.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/quotas.TestQuotaStatusRPCs.java,**/regionserver.TestHRegionWithInMemoryFlush.java,**/master.cleaner.TestHFileCleaner.java
> clean test -fae > /testptch/patchprocess/patch-unit-root.txt 2>&1
> 13:00:13 Build was aborted
> ...
> {code}
> I'd aborted the run because it seemed to be taking too long but on subsequent
> examination, it was actually making progress.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18901) Support build with CMake
[ https://issues.apache.org/jira/browse/HBASE-18901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202386#comment-16202386 ] marco polo commented on HBASE-18901: I'll be happy to provide some information in the README regarding dependencies and how to build. I can do that under this ticket or a sub task. Just let me know. > Support build with CMake > > > Key: HBASE-18901 > URL: https://issues.apache.org/jira/browse/HBASE-18901 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: marco polo > Labels: C++ > Fix For: HBASE-14850 > > Attachments: HBASE-18901.v1.HBASE-14850.patch, > HBASE-18901.v2.HBASE-14850.patch > > > I've co-opted some help from folks in trying to support CMake as the build > tool instead of Buck. > They have something working, but need to consolidate the patch. Filing an > issue for them to put a patch on. > FYI [~enis], [~tedyu] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18996) Backport HBASE-17703 (TestThriftServerCmdLine is flaky in master branch) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-18996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16202383#comment-16202383
]
Hadoop QA commented on HBASE-18996:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
| {color: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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
58s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
2s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
19s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
20s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
41s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
22s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
25s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
36s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 17s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 18m 32s{color}
| {color:red} hbase-thrift in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 57m 58s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18996 |
| JIRA Patch URL |
