[jira] [Created] (HBASE-22256) Enabling FavoredStochasticBalancer on existing cluster leaves regions unassigned
Nikhil Bafna created HBASE-22256: Summary: Enabling FavoredStochasticBalancer on existing cluster leaves regions unassigned Key: HBASE-22256 URL: https://issues.apache.org/jira/browse/HBASE-22256 Project: HBase Issue Type: Bug Components: Balancer Affects Versions: 2.1.3 Reporter: Nikhil Bafna This is related to HBASE-18349. The test that fails corresponding to this is TestFavoredStochasticLoadBalancer#testMisplacedRegions. When a region is misplaced w.r.t to the favored nodes, this balancer unassigns the region and the new RegionPlan has the source server as null leading to NPE later. This leaves the affected regions to be unassigned after the balancer run. This is problematic especially when moving from a different balancer to the FavoredStochasticLoadBalancer because all regions would be "misplaced" in the favored balancer's run. The fix is along the lines of HBASE-18602. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21937) Make the Compression#decompress can accept ByteBuff as input
[
https://issues.apache.org/jira/browse/HBASE-21937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819739#comment-16819739
]
HBase QA commented on HBASE-21937:
--
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
33s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
26s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
10s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 2m
53s{color} | {color:blue} hbase-server in HBASE-21879 has 11 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} HBASE-21879 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} hbase-common: The patch generated 0 new + 8
unchanged - 1 fixed = 8 total (was 9) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} hbase-server: The patch generated 0 new + 26
unchanged - 1 fixed = 26 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} 4m
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 5s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
33s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}142m
38s{color} | {color:green} hbase-server in the patch passed. {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}189m 8s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/105/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-21937 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12966172/HBASE-21937.HBASE-21879.v3.patch
|
| Optional Tests | dupname asflicense javac javadoc unit findbugs
shadedjars hadoopcheck hbaseanti checkstyle compile |
| uname | Linux
[jira] [Commented] (HBASE-17969) Balance by table using SimpleLoadBalancer could end up imbalance
[ https://issues.apache.org/jira/browse/HBASE-17969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819691#comment-16819691 ] Yu Li commented on HBASE-17969: --- Yes I think we could mark this as duplicate of FLINK-17110. On the other hand, FLINK-17110 was only merged into master and available in 2.x, so if anyone still requires this in branch-1, we should open another explicit one for the backport. > Balance by table using SimpleLoadBalancer could end up imbalance > > > Key: HBASE-17969 > URL: https://issues.apache.org/jira/browse/HBASE-17969 > Project: HBase > Issue Type: Improvement > Components: Balancer >Affects Versions: 1.1.10 >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-17969-branch-1.patch, > HBASE-17969-branch-1.v2.patch, HBASE-17969-branch-1.v3.patch, > HBASE-17969.patch > > > This really happens in our production env. > Here is a example: > Say we have three RS named r1, r2, r3. A table named table1 with 3 regions > distributes on these rs like this: > r1 1 > r2 1 > r3 1 > Each rs have one region, it means table1 is balanced. So balancer will not > run. > If the region on r3 splits, then it becomes: > r1 1 > r2 1 > r3 2 > For table1, in average, each rs will have min=1, max=2 regions. So still it > is balanced, balancer will not run. > Then a region on r3 splits again, the distribution becomes: > r1 1 > r2 1 > r3 3 > In average, each rs will have min=1, max=2 regions. So balancer will run. > For r1 and r2, they have already have min=1 regions. Balancer won't do any > operation on them. > But for r3, it exceed max=3, so balancer will remove one region from r3 and > choose one rs from r1, r2 to move to. > But r1 and r2 have the same load, so balancer will always choose r1 since > servername r1 < r2(alphabet order, sorted by ServerAndLoad's compareTo > method). It is OK for table1 itself. But if every table in the cluster have > similar situations like table1, then the load in the cluster will always be > like r1 > r2 > r3. > So, the solution here is when each rs reach min regions (min=total region / > servers), but there still some region need to move, shuffle the regionservers > before move. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22254) refactor and improve decommissioning logic
[
https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819689#comment-16819689
]
HBase QA commented on HBASE-22254:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
56s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
40s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
53s{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} 13m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
13s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {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} 4m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
59s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
18s{color} | {color:red} hbase-server: The patch generated 4 new + 216
unchanged - 3 fixed = 220 total (was 219) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
1s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
37s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 1s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
2m 21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 5m
43s{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} 1m
29s{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
3s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
47s{color} | {color:green} hbase-zookeeper in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}223m 48s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
53s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
46s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}316m 47s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| FindBugs | module:hbase-server |
| | Dead store to decomList in
[jira] [Commented] (HBASE-22020) upgrade to yetus 0.9.0
[
https://issues.apache.org/jira/browse/HBASE-22020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819685#comment-16819685
]
Hudson commented on HBASE-22020:
Results for branch HBASE-22020
[build #14 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/14/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/14//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/14//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-22020/14//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> upgrade to yetus 0.9.0
> --
>
> Key: HBASE-22020
> URL: https://issues.apache.org/jira/browse/HBASE-22020
> Project: HBase
> Issue Type: Task
> Components: build, community
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-22020-branch-1.v1.patch, HBASE-22020.0.patch,
> HBASE-22020.1.patch
>
>
> branch-1/jdk7 checkstyle dtd xml parse complaint; "script engine for language
> js can not be found"
> See parent for some context. Checkstyle references dtds that were hosted on
> puppycrawl, then on sourceforge up until ten days ago. Nightlies are failing
> for among other reasons, complaint that there is bad xml in the build...
> notably, the unresolvable DTDs.
> I'd just update the DTDs but there is a need for a js engine some where and
> openjdk7 doesn't ship with one (openjdk8 does). That needs addressing and
> then we can backport the parent issue...
> See
> https://builds.apache.org/view/H-L/view/HBase/job/HBase%20Nightly/job/branch-1/710/artifact/output-general/xml.txt
> ... which in case its rolled away, is filled with this message:
> "script engine for language js can not be found"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22184) [security] Support get|set LogLevel in HTTPS mode
[ https://issues.apache.org/jira/browse/HBASE-22184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reid Chan updated HBASE-22184: -- Labels: security (was: ) > [security] Support get|set LogLevel in HTTPS mode > - > > Key: HBASE-22184 > URL: https://issues.apache.org/jira/browse/HBASE-22184 > Project: HBase > Issue Type: Improvement > Components: logging, website >Reporter: Reid Chan >Assignee: Wei-Chiu Chuang >Priority: Major > Labels: security > > As title read. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21048) Get LogLevel is not working from console in secure environment
[
https://issues.apache.org/jira/browse/HBASE-21048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan updated HBASE-21048:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Release Note: Support get|set LogLevel in secure(kerberized) environment.
Status: Resolved (was: Patch Available)
> Get LogLevel is not working from console in secure environment
> --
>
> Key: HBASE-21048
> URL: https://issues.apache.org/jira/browse/HBASE-21048
> Project: HBase
> Issue Type: Bug
>Reporter: Chandra Sekhar
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Labels: security
> Fix For: 3.0.0, 2.3.0, 1.6.0
>
> Attachments: HBASE-21048.001.patch, HBASE-21048.branch-1.001.patch,
> HBASE-21048.branch-1.002.patch, HBASE-21048.master.001.patch,
> HBASE-21048.master.002.patch, HBASE-21048.master.003.patch,
> HBASE-21048.master.004.patch, HBASE-21048.master.005.patch,
> HBASE-21048.master.006.patch, HBASE-21048.master.007.patch,
> HBASE-21048.master.008.patch
>
>
> When we try to get log level of specific package in secure environment,
> getting SocketException.
> {code:java}
> hbase/master/bin# ./hbase org.apache.hadoop.hbase.http.log.LogLevel -getlevel
> host-:16010 org.apache.hadoop.hbase
> Connecting to http://host-:16010/logLevel?log=org.apache.hadoop.hbase
> java.net.SocketException: Unexpected end of file from server
> {code}
> It is trying to connect http instead of https
> code snippet that handling only http in *LogLevel.java*
> {code:java}
> public static void main(String[] args) {
> if (args.length == 3 && "-getlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]);
> return;
> }
> else if (args.length == 4 && "-setlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]
> + "=" + args[3]);
> return;
> }
> System.err.println(USAGES);
> System.exit(-1);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21048) Get LogLevel is not working from console in secure environment
[
https://issues.apache.org/jira/browse/HBASE-21048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reid Chan updated HBASE-21048:
--
Fix Version/s: 1.6.0
> Get LogLevel is not working from console in secure environment
> --
>
> Key: HBASE-21048
> URL: https://issues.apache.org/jira/browse/HBASE-21048
> Project: HBase
> Issue Type: Bug
>Reporter: Chandra Sekhar
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Labels: security
> Fix For: 3.0.0, 2.3.0, 1.6.0
>
> Attachments: HBASE-21048.001.patch, HBASE-21048.branch-1.001.patch,
> HBASE-21048.branch-1.002.patch, HBASE-21048.master.001.patch,
> HBASE-21048.master.002.patch, HBASE-21048.master.003.patch,
> HBASE-21048.master.004.patch, HBASE-21048.master.005.patch,
> HBASE-21048.master.006.patch, HBASE-21048.master.007.patch,
> HBASE-21048.master.008.patch
>
>
> When we try to get log level of specific package in secure environment,
> getting SocketException.
> {code:java}
> hbase/master/bin# ./hbase org.apache.hadoop.hbase.http.log.LogLevel -getlevel
> host-:16010 org.apache.hadoop.hbase
> Connecting to http://host-:16010/logLevel?log=org.apache.hadoop.hbase
> java.net.SocketException: Unexpected end of file from server
> {code}
> It is trying to connect http instead of https
> code snippet that handling only http in *LogLevel.java*
> {code:java}
> public static void main(String[] args) {
> if (args.length == 3 && "-getlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]);
> return;
> }
> else if (args.length == 4 && "-setlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]
> + "=" + args[3]);
> return;
> }
> System.err.println(USAGES);
> System.exit(-1);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21048) Get LogLevel is not working from console in secure environment
[
https://issues.apache.org/jira/browse/HBASE-21048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819684#comment-16819684
]
Reid Chan commented on HBASE-21048:
---
Pushed to branch-1
> Get LogLevel is not working from console in secure environment
> --
>
> Key: HBASE-21048
> URL: https://issues.apache.org/jira/browse/HBASE-21048
> Project: HBase
> Issue Type: Bug
>Reporter: Chandra Sekhar
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Labels: security
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21048.001.patch, HBASE-21048.branch-1.001.patch,
> HBASE-21048.branch-1.002.patch, HBASE-21048.master.001.patch,
> HBASE-21048.master.002.patch, HBASE-21048.master.003.patch,
> HBASE-21048.master.004.patch, HBASE-21048.master.005.patch,
> HBASE-21048.master.006.patch, HBASE-21048.master.007.patch,
> HBASE-21048.master.008.patch
>
>
> When we try to get log level of specific package in secure environment,
> getting SocketException.
> {code:java}
> hbase/master/bin# ./hbase org.apache.hadoop.hbase.http.log.LogLevel -getlevel
> host-:16010 org.apache.hadoop.hbase
> Connecting to http://host-:16010/logLevel?log=org.apache.hadoop.hbase
> java.net.SocketException: Unexpected end of file from server
> {code}
> It is trying to connect http instead of https
> code snippet that handling only http in *LogLevel.java*
> {code:java}
> public static void main(String[] args) {
> if (args.length == 3 && "-getlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]);
> return;
> }
> else if (args.length == 4 && "-setlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]
> + "=" + args[3]);
> return;
> }
> System.err.println(USAGES);
> System.exit(-1);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21048) Get LogLevel is not working from console in secure environment
[
https://issues.apache.org/jira/browse/HBASE-21048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819683#comment-16819683
]
Reid Chan commented on HBASE-21048:
---
+1 for branch-1 v2, thanks! [~jojochuang].
Let's start HBASE-22184!
> Get LogLevel is not working from console in secure environment
> --
>
> Key: HBASE-21048
> URL: https://issues.apache.org/jira/browse/HBASE-21048
> Project: HBase
> Issue Type: Bug
>Reporter: Chandra Sekhar
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Labels: security
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21048.001.patch, HBASE-21048.branch-1.001.patch,
> HBASE-21048.branch-1.002.patch, HBASE-21048.master.001.patch,
> HBASE-21048.master.002.patch, HBASE-21048.master.003.patch,
> HBASE-21048.master.004.patch, HBASE-21048.master.005.patch,
> HBASE-21048.master.006.patch, HBASE-21048.master.007.patch,
> HBASE-21048.master.008.patch
>
>
> When we try to get log level of specific package in secure environment,
> getting SocketException.
> {code:java}
> hbase/master/bin# ./hbase org.apache.hadoop.hbase.http.log.LogLevel -getlevel
> host-:16010 org.apache.hadoop.hbase
> Connecting to http://host-:16010/logLevel?log=org.apache.hadoop.hbase
> java.net.SocketException: Unexpected end of file from server
> {code}
> It is trying to connect http instead of https
> code snippet that handling only http in *LogLevel.java*
> {code:java}
> public static void main(String[] args) {
> if (args.length == 3 && "-getlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]);
> return;
> }
> else if (args.length == 4 && "-setlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]
> + "=" + args[3]);
> return;
> }
> System.err.println(USAGES);
> System.exit(-1);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21937) Make the Compression#decompress can accept ByteBuff as input
[
https://issues.apache.org/jira/browse/HBASE-21937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-21937:
-
Attachment: HBASE-21937.HBASE-21879.v3.patch
> Make the Compression#decompress can accept ByteBuff as input
> -
>
> Key: HBASE-21937
> URL: https://issues.apache.org/jira/browse/HBASE-21937
> Project: HBase
> Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Attachments: HBASE-21937.HBASE-21879.v1.patch,
> HBASE-21937.HBASE-21879.v2.patch, HBASE-21937.HBASE-21879.v3.patch
>
>
> When decompressing an compressed block, we are also allocating
> HeapByteBuffer for the unpacked block. should allocate ByteBuff from the
> global ByteBuffAllocator, skimmed the code, the key point is, we need an
> ByteBuff decompress interface, not the following:
> {code}
> # Compression.java
> public static void decompress(byte[] dest, int destOffset,
> InputStream bufferedBoundedStream, int compressedSize,
> int uncompressedSize, Compression.Algorithm compressAlgo)
> throws IOException {
> //...
> }
> {code}
> Not very high priority, let me make the block without compression to be
> offheap firstly.
> In HBASE-22005, I ignored the unit test:
> 1. TestLoadAndSwitchEncodeOnDisk ;
> 2. TestHFileBlock#testPreviousOffset;
> Need to resolve this issue and make those UT works fine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21957) Unify refCount of BucketEntry and refCount of hbase.nio.ByteBuff into one
[ https://issues.apache.org/jira/browse/HBASE-21957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819656#comment-16819656 ] Zheng Hu commented on HBASE-21957: -- [~anoop.hbase], [~Apache9], [~ram_krish] , any other concerns about the patch.v8 ? > Unify refCount of BucketEntry and refCount of hbase.nio.ByteBuff into one > - > > Key: HBASE-21957 > URL: https://issues.apache.org/jira/browse/HBASE-21957 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-21957.HBASE-21879.v1.patch, > HBASE-21957.HBASE-21879.v2.patch, HBASE-21957.HBASE-21879.v3.patch, > HBASE-21957.HBASE-21879.v4.patch, HBASE-21957.HBASE-21879.v5.patch, > HBASE-21957.HBASE-21879.v6.patch, HBASE-21957.HBASE-21879.v8.patch > > > After HBASE-12295, we have block with MemoryType.SHARED or > MemoryType.EXCLUSIVE, the block in offheap BucketCache will be shared, and > have an reference count to track its life cycle. If no rpc reference to the > shared block, then the block can be evicted. > while after the HBASE-21916, we introduced an refcount for ByteBuff, then I > think we can unify the two into one. tried to fix this when preparing patch > for HBASE-21879, but seems can be different sub-task, and it won't affect the > main logic of HBASE-21879, so create a seperate one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8
Apache-HBase commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8 URL: https://github.com/apache/hbase/pull/136#issuecomment-483885745 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 273 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 4 new or modified test files. | ||| _ master Compile Tests _ | | 0 | mvndep | 32 | Maven dependency ordering for branch | | +1 | mvninstall | 305 | master passed | | +1 | compile | 162 | master passed | | +1 | checkstyle | 146 | master passed | | +1 | shadedjars | 338 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 390 | master passed | | +1 | javadoc | 105 | master passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 16 | Maven dependency ordering for patch | | +1 | mvninstall | 299 | the patch passed | | +1 | compile | 164 | the patch passed | | +1 | javac | 164 | the patch passed | | +1 | checkstyle | 135 | the patch passed | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 332 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 660 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 422 | the patch passed | | +1 | javadoc | 174 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 13636 | hbase-server in the patch passed. | | +1 | unit | 1373 | hbase-mapreduce in the patch passed. | | +1 | unit | 582 | hbase-rest in the patch passed. | | +1 | unit | 143 | hbase-examples in the patch passed. | | +1 | asflicense | 113 | The patch does not generate ASF License warnings. | | | | 19978 | | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/5/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/136 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 94b82e2106b6 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 20f72f5e25 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/5/testReport/ | | Max. process+thread count | 5526 (vs. ulimit of 1) | | modules | C: hbase-server hbase-mapreduce hbase-rest hbase-examples U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/5/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819599#comment-16819599
]
Hudson commented on HBASE-22235:
FAILURE: Integrated in Jenkins build HBase-1.2-IT #1220 (See
[https://builds.apache.org/job/HBase-1.2-IT/1220/])
HBASE-22235 OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to
(apurtell:
[https://github.com/apache/hbase/commit/fcff6538194ff3549f33db488e3315bf6e21a0bf])
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/OperationStatus.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 1.2.12, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22216) "Waiting on master failover to complete" shows 30 to 40 time per milliseconds
[ https://issues.apache.org/jira/browse/HBASE-22216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankit Jain updated HBASE-22216: --- Summary: "Waiting on master failover to complete" shows 30 to 40 time per milliseconds (was: "Waiting on master failover to complete" shows 30 to 40 time per millisecond ) > "Waiting on master failover to complete" shows 30 to 40 time per milliseconds > -- > > Key: HBASE-22216 > URL: https://issues.apache.org/jira/browse/HBASE-22216 > Project: HBase > Issue Type: Bug > Components: logging, Operability, proc-v2 >Affects Versions: 1.3.0 >Reporter: Xu Cang >Assignee: Ankit Jain >Priority: Minor > > "Waiting on master failover to complete" appears 30 to 40 times per > *millisecond* from one host when master is initializing. > This message is too noisy, epecially when there are issues when master init. > Should fix this by either rate-limiting or even revisit is that normal > #executeFromState gets called 30-40 times per ms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21048) Get LogLevel is not working from console in secure environment
[
https://issues.apache.org/jira/browse/HBASE-21048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819597#comment-16819597
]
Wei-Chiu Chuang commented on HBASE-21048:
-
As far as I can tell the test failed for an unrelated issue. Also the test
doesn't fail on my local laptop
> Get LogLevel is not working from console in secure environment
> --
>
> Key: HBASE-21048
> URL: https://issues.apache.org/jira/browse/HBASE-21048
> Project: HBase
> Issue Type: Bug
>Reporter: Chandra Sekhar
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Labels: security
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21048.001.patch, HBASE-21048.branch-1.001.patch,
> HBASE-21048.branch-1.002.patch, HBASE-21048.master.001.patch,
> HBASE-21048.master.002.patch, HBASE-21048.master.003.patch,
> HBASE-21048.master.004.patch, HBASE-21048.master.005.patch,
> HBASE-21048.master.006.patch, HBASE-21048.master.007.patch,
> HBASE-21048.master.008.patch
>
>
> When we try to get log level of specific package in secure environment,
> getting SocketException.
> {code:java}
> hbase/master/bin# ./hbase org.apache.hadoop.hbase.http.log.LogLevel -getlevel
> host-:16010 org.apache.hadoop.hbase
> Connecting to http://host-:16010/logLevel?log=org.apache.hadoop.hbase
> java.net.SocketException: Unexpected end of file from server
> {code}
> It is trying to connect http instead of https
> code snippet that handling only http in *LogLevel.java*
> {code:java}
> public static void main(String[] args) {
> if (args.length == 3 && "-getlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]);
> return;
> }
> else if (args.length == 4 && "-setlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]
> + "=" + args[3]);
> return;
> }
> System.err.println(USAGES);
> System.exit(-1);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
[
https://issues.apache.org/jira/browse/HBASE-21512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819591#comment-16819591
]
Hudson commented on HBASE-21512:
Results for branch HBASE-21512
[build #181 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/181/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/181//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/181//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/181//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
> Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need
> to set a delay and use a thread pool any more, which could reduce the
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely,
> and start to rewrite the old sync client based on the async client, which
> could reduce the code base a lot for our client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21048) Get LogLevel is not working from console in secure environment
[
https://issues.apache.org/jira/browse/HBASE-21048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819581#comment-16819581
]
HBase QA commented on HBASE-21048:
--
| (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:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m
41s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
39s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
16s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
44s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
36s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
37s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
37s{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 with JDK v1.7.0_211 {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} 1m
16s{color} | {color:green} hbase-server: The patch generated 0 new + 1
unchanged - 16 fixed = 1 total (was 17) {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
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
1m 42s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{color} | {color:green} the patch passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}107m 3s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}132m 0s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.regionserver.TestMultiColumnScannerWithAlgoGZAndNoDataEncoding |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
https://builds.apache.org/job/PreCommit-HBASE-Build/101/artifact/patchprocess/Dockerfile
|
| JIRA Issue | HBASE-21048 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12966145/HBASE-21048.branch-1.002.patch
|
| Optional Tests | dupname asflicense
[jira] [Commented] (HBASE-22201) Multiple test case failures
[
https://issues.apache.org/jira/browse/HBASE-22201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819575#comment-16819575
]
HBase QA commented on HBASE-22201:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-22201 does not apply to master. Rebase required? Wrong
Branch? See
https://yetus.apache.org/documentation/in-progress/precommit-patchnames for
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-22201 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12966156/HBASE-22201-HBASE-14850.v1.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/104/console |
| Powered by | Apache Yetus 0.9.0 http://yetus.apache.org |
This message was automatically generated.
> Multiple test case failures
> ---
>
> Key: HBASE-22201
> URL: https://issues.apache.org/jira/browse/HBASE-22201
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: HBASE-14850
>Reporter: Ian Buss
>Assignee: Ian Buss
>Priority: Major
> Attachments: HBASE-22201-HBASE-14850.v0.patch,
> HBASE-22201-HBASE-14850.v1.patch
>
>
> result-test.cc fails on EstimatedSize assertion:
> The test assumes {{sizeof(Result)}} will be the same as the estimated size of
> an empty Result which is not the case because estimated size also accounts
> for current capacity of its {{row_}} string member.
> When using docker::
> * Classpath is not propagated properly within the docker container:
> ** if you follow the documentation and build the java project before
> starting docker the classpath file contains the wrong paths. also the code to
> read from a CLASSPATH env var doesn't quite work as expected
> * MiniCluster is not writing an hbase-site.xml to disk as expected by some
> of the tests—as a result the default zk port of 2181 is being used by clients
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22201) Multiple test case failures
[
https://issues.apache.org/jira/browse/HBASE-22201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Buss updated HBASE-22201:
-
Attachment: HBASE-22201-HBASE-14850.v1.patch
> Multiple test case failures
> ---
>
> Key: HBASE-22201
> URL: https://issues.apache.org/jira/browse/HBASE-22201
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: HBASE-14850
>Reporter: Ian Buss
>Assignee: Ian Buss
>Priority: Major
> Attachments: HBASE-22201-HBASE-14850.v0.patch,
> HBASE-22201-HBASE-14850.v1.patch
>
>
> result-test.cc fails on EstimatedSize assertion:
> The test assumes {{sizeof(Result)}} will be the same as the estimated size of
> an empty Result which is not the case because estimated size also accounts
> for current capacity of its {{row_}} string member.
> When using docker::
> * Classpath is not propagated properly within the docker container:
> ** if you follow the documentation and build the java project before
> starting docker the classpath file contains the wrong paths. also the code to
> read from a CLASSPATH env var doesn't quite work as expected
> * MiniCluster is not writing an hbase-site.xml to disk as expected by some
> of the tests—as a result the default zk port of 2181 is being used by clients
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22201) Multiple test case failures
[
https://issues.apache.org/jira/browse/HBASE-22201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Buss updated HBASE-22201:
-
Status: Patch Available (was: Open)
> Multiple test case failures
> ---
>
> Key: HBASE-22201
> URL: https://issues.apache.org/jira/browse/HBASE-22201
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: HBASE-14850
>Reporter: Ian Buss
>Assignee: Ian Buss
>Priority: Major
> Attachments: HBASE-22201-HBASE-14850.v0.patch,
> HBASE-22201-HBASE-14850.v1.patch
>
>
> result-test.cc fails on EstimatedSize assertion:
> The test assumes {{sizeof(Result)}} will be the same as the estimated size of
> an empty Result which is not the case because estimated size also accounts
> for current capacity of its {{row_}} string member.
> When using docker::
> * Classpath is not propagated properly within the docker container:
> ** if you follow the documentation and build the java project before
> starting docker the classpath file contains the wrong paths. also the code to
> read from a CLASSPATH env var doesn't quite work as expected
> * MiniCluster is not writing an hbase-site.xml to disk as expected by some
> of the tests—as a result the default zk port of 2181 is being used by clients
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819568#comment-16819568
]
Hudson commented on HBASE-22235:
SUCCESS: Integrated in Jenkins build HBase-1.3-IT #543 (See
[https://builds.apache.org/job/HBase-1.3-IT/543/])
HBASE-22235 OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to
(apurtell:
[https://github.com/apache/hbase/commit/d27ca2d647efc7d60d918c3efc2f445bb60db1b1])
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/OperationStatus.java
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 1.2.12, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22201) Multiple test case failures
[
https://issues.apache.org/jira/browse/HBASE-22201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Buss updated HBASE-22201:
-
Attachment: (was: HBASE-22201-HBASE-14850.v1.patch)
> Multiple test case failures
> ---
>
> Key: HBASE-22201
> URL: https://issues.apache.org/jira/browse/HBASE-22201
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: HBASE-14850
>Reporter: Ian Buss
>Assignee: Ian Buss
>Priority: Major
> Attachments: HBASE-22201-HBASE-14850.v0.patch
>
>
> result-test.cc fails on EstimatedSize assertion:
> The test assumes {{sizeof(Result)}} will be the same as the estimated size of
> an empty Result which is not the case because estimated size also accounts
> for current capacity of its {{row_}} string member.
> When using docker::
> * Classpath is not propagated properly within the docker container:
> ** if you follow the documentation and build the java project before
> starting docker the classpath file contains the wrong paths. also the code to
> read from a CLASSPATH env var doesn't quite work as expected
> * MiniCluster is not writing an hbase-site.xml to disk as expected by some
> of the tests—as a result the default zk port of 2181 is being used by clients
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22201) Multiple test case failures
[
https://issues.apache.org/jira/browse/HBASE-22201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Buss updated HBASE-22201:
-
Attachment: HBASE-22201-HBASE-14850.v1.patch
> Multiple test case failures
> ---
>
> Key: HBASE-22201
> URL: https://issues.apache.org/jira/browse/HBASE-22201
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: HBASE-14850
>Reporter: Ian Buss
>Assignee: Ian Buss
>Priority: Major
> Attachments: HBASE-22201-HBASE-14850.v0.patch
>
>
> result-test.cc fails on EstimatedSize assertion:
> The test assumes {{sizeof(Result)}} will be the same as the estimated size of
> an empty Result which is not the case because estimated size also accounts
> for current capacity of its {{row_}} string member.
> When using docker::
> * Classpath is not propagated properly within the docker container:
> ** if you follow the documentation and build the java project before
> starting docker the classpath file contains the wrong paths. also the code to
> read from a CLASSPATH env var doesn't quite work as expected
> * MiniCluster is not writing an hbase-site.xml to disk as expected by some
> of the tests—as a result the default zk port of 2181 is being used by clients
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22201) Multiple test case failures
[
https://issues.apache.org/jira/browse/HBASE-22201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819567#comment-16819567
]
Ian Buss commented on HBASE-22201:
--
Submitting patch to address a number of issues:
* fix classpath and meta region spec (wrong meta region name being specified)
* fix result-test failing on EstimatedSize assertion
* allow classpath to be set through env var and use correct classpath file
path for makefile
* update building instructions
* cleanup env between tests
* fix cell-tests which don't take string capacity into account with size
estimates
> Multiple test case failures
> ---
>
> Key: HBASE-22201
> URL: https://issues.apache.org/jira/browse/HBASE-22201
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: HBASE-14850
>Reporter: Ian Buss
>Assignee: Ian Buss
>Priority: Major
> Attachments: HBASE-22201-HBASE-14850.v0.patch
>
>
> result-test.cc fails on EstimatedSize assertion:
> The test assumes {{sizeof(Result)}} will be the same as the estimated size of
> an empty Result which is not the case because estimated size also accounts
> for current capacity of its {{row_}} string member.
> When using docker::
> * Classpath is not propagated properly within the docker container:
> ** if you follow the documentation and build the java project before
> starting docker the classpath file contains the wrong paths. also the code to
> read from a CLASSPATH env var doesn't quite work as expected
> * MiniCluster is not writing an hbase-site.xml to disk as expected by some
> of the tests—as a result the default zk port of 2181 is being used by clients
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819566#comment-16819566
]
Hudson commented on HBASE-22235:
Results for branch branch-1.3
[build #728 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/728/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/728//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/728//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/728//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 1.2.12, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22255) Process for gaining access to slack and mailing lists
[ https://issues.apache.org/jira/browse/HBASE-22255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Shen updated HBASE-22255: - Issue Type: Task (was: Bug) > Process for gaining access to slack and mailing lists > - > > Key: HBASE-22255 > URL: https://issues.apache.org/jira/browse/HBASE-22255 > Project: HBase > Issue Type: Task >Reporter: Evelina Dumitrescu >Assignee: William Shen >Priority: Trivial > > Hello, > > In the getting started documentation it is written to email the dev list in > order to get access to the slack channel. > Unfortunately, as a new user I didn't manage to send the email to the dev and > user lists. I checked the mailing lists archive and I couldn't find my emails > there. > What is the procedure for gaining access to the slack and mailing lists in > order to start making contributions? > > Thank you, > Evelina -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22255) Process for gaining access to slack and mailing lists
[ https://issues.apache.org/jira/browse/HBASE-22255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Shen updated HBASE-22255: - Priority: Trivial (was: Major) > Process for gaining access to slack and mailing lists > - > > Key: HBASE-22255 > URL: https://issues.apache.org/jira/browse/HBASE-22255 > Project: HBase > Issue Type: Bug >Reporter: Evelina Dumitrescu >Assignee: William Shen >Priority: Trivial > > Hello, > > In the getting started documentation it is written to email the dev list in > order to get access to the slack channel. > Unfortunately, as a new user I didn't manage to send the email to the dev and > user lists. I checked the mailing lists archive and I couldn't find my emails > there. > What is the procedure for gaining access to the slack and mailing lists in > order to start making contributions? > > Thank you, > Evelina -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-22255) Process for gaining access to slack and mailing lists
[ https://issues.apache.org/jira/browse/HBASE-22255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Shen resolved HBASE-22255. -- Resolution: Done Assignee: William Shen [~evelinad], I've invited to the slack channel, and your email did get send out to the lists correctly. > Process for gaining access to slack and mailing lists > - > > Key: HBASE-22255 > URL: https://issues.apache.org/jira/browse/HBASE-22255 > Project: HBase > Issue Type: Bug >Reporter: Evelina Dumitrescu >Assignee: William Shen >Priority: Major > > Hello, > > In the getting started documentation it is written to email the dev list in > order to get access to the slack channel. > Unfortunately, as a new user I didn't manage to send the email to the dev and > user lists. I checked the mailing lists archive and I couldn't find my emails > there. > What is the procedure for gaining access to the slack and mailing lists in > order to start making contributions? > > Thank you, > Evelina -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-4191) hbase load balancer needs locality awareness
[ https://issues.apache.org/jira/browse/HBASE-4191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819546#comment-16819546 ] Biju Nair commented on HBASE-4191: -- With SLB (HBASE-5959) taking into account data locality, this requirement is satisfied. no [~yuzhih...@gmail.com]? Not sure about the last comment from [~stack] for this to be closed. > hbase load balancer needs locality awareness > > > Key: HBASE-4191 > URL: https://issues.apache.org/jira/browse/HBASE-4191 > Project: HBase > Issue Type: New Feature > Components: Balancer >Reporter: Ted Yu >Assignee: Liyin Tang >Priority: Major > > Previously, HBASE-4114 implements the metrics for HFile HDFS block locality, > which provides the HFile level locality information. > But in order to work with load balancer and region assignment, we need the > region level locality information. > Let's define the region locality information first, which is almost the same > as HFile locality index. > HRegion locality index (HRegion A, RegionServer B) = > (Total number of HDFS blocks that can be retrieved locally by the > RegionServer B for the HRegion A) / ( Total number of the HDFS blocks for the > Region A) > So the HRegion locality index tells us that how much locality we can get if > the HMaster assign the HRegion A to the RegionServer B. > So there will be 2 steps involved to assign regions based on the locality. > 1) During the cluster start up time, the master will scan the hdfs to > calculate the "HRegion locality index" for each pair of HRegion and Region > Server. It is pretty expensive to scan the dfs. So we only needs to do this > once during the start up time. > 2) During the cluster run time, each region server will update the "HRegion > locality index" as metrics periodically as HBASE-4114 did. The Region Server > can expose them to the Master through ZK, meta table, or just RPC messages. > Based on the "HRegion locality index", the assignment manager in the master > would have a global knowledge about the region locality distribution and can > run the MIN COST MAXIMUM FLOW solver to reach the global optimization. > Let's construct the graph first: > [Graph] > Imaging there is a bipartite graph and the left side is the set of regions > and the right side is the set of region servers. > There is a source node which links itself to each node in the region set. > There is a sink node which is linked from each node in the region server set. > [Capacity] > The capacity between the source node and region nodes is 1. > And the capacity between the region nodes and region server nodes is also 1. > (The purpose is each region can ONLY be assigned to one region server at one > time) > The capacity between the region server nodes and sink node are the avg number > of regions which should be assigned each region server. > (The purpose is balance the load for each region server) > [Cost] > The cost between each region and region server is the opposite of locality > index, which means the higher locality is, if region A is assigned to region > server B, the lower cost it is. > The cost function could be more sophisticated when we put more metrics into > account. > So after running the min-cost max flow solver, the master could assign the > regions based on the global locality optimization. > Also the master should share this global view to secondary master in case the > master fail over happens. > In addition, the HBASE-4491 (Locality Checker) is the tool, which is based on > the same metrics, to proactively to scan dfs to calculate the global locality > information in the cluster. It will help us to verify data locality > information during the run time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22254) refactor and improve decommissioning logic
[ https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22254: - Attachment: (was: HBASE-22254.patch) > refactor and improve decommissioning logic > -- > > Key: HBASE-22254 > URL: https://issues.apache.org/jira/browse/HBASE-22254 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22254.patch > > > Making some changes needed to support better decommissioning on large > clusters and with container mode; to test those and add clarify I moved parts > of decommissioning logic from HMaster, Draining tracker, and ServerManager > into a separate class. > Features added/improvements: > 1) More resilient off-loading; right now off-loading fails for a subset of > regions in case of a single region failure; is never done on master restart, > etc. > 2) Option to kill RS after off-loading (good for container mode HBase, e.g. > on YARN). > 3) Option to specify machine names only to decommission, for the API to be > usable for an external system that doesn't care about HBase server names, or > e.g. multiple RS in containers on the same node. > 4) Option to replace existing decommissioning list instead of adding to it > (the same; to avoid additionally remembering what was previously sent to > HBase). > 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22254) refactor and improve decommissioning logic
[ https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22254: - Attachment: HBASE-22254.patch > refactor and improve decommissioning logic > -- > > Key: HBASE-22254 > URL: https://issues.apache.org/jira/browse/HBASE-22254 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22254.patch > > > Making some changes needed to support better decommissioning on large > clusters and with container mode; to test those and add clarify I moved parts > of decommissioning logic from HMaster, Draining tracker, and ServerManager > into a separate class. > Features added/improvements: > 1) More resilient off-loading; right now off-loading fails for a subset of > regions in case of a single region failure; is never done on master restart, > etc. > 2) Option to kill RS after off-loading (good for container mode HBase, e.g. > on YARN). > 3) Option to specify machine names only to decommission, for the API to be > usable for an external system that doesn't care about HBase server names, or > e.g. multiple RS in containers on the same node. > 4) Option to replace existing decommissioning list instead of adding to it > (the same; to avoid additionally remembering what was previously sent to > HBase). > 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22254) refactor and improve decommissioning logic
[
https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819539#comment-16819539
]
HBase QA commented on HBASE-22254:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 4m
50s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
33s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
54s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
27s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 2m
43s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
16s{color} | {color:red} hbase-zookeeper in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
44s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
26s{color} | {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 16s{color} |
{color:red} hbase-zookeeper in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 44s{color} |
{color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 26s{color} |
{color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 16s{color}
| {color:red} hbase-zookeeper in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 44s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 26s{color}
| {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
11s{color} | {color:red} The patch fails to run checkstyle in hbase-zookeeper
{color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
25s{color} | {color:red} hbase-server: The patch generated 4 new + 216
unchanged - 3 fixed = 220 total (was 219) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 3m
40s{color} | {color:red} patch has 212 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
37s{color} | {color:red} The patch causes 212 errors with Hadoop v2.7.4.
{color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
19s{color} | {color:red} The patch causes 212 errors with Hadoop v3.0.0.
{color} |
| {color:red}-1{color} | {color:red} hbaseprotoc {color} | {color:red} 0m
16s{color} | {color:red} hbase-zookeeper in the patch failed. {color} |
| {color:red}-1{color} | {color:red} hbaseprotoc {color} | {color:red} 0m
42s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} hbaseprotoc
[jira] [Commented] (HBASE-17969) Balance by table using SimpleLoadBalancer could end up imbalance
[ https://issues.apache.org/jira/browse/HBASE-17969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819534#comment-16819534 ] Biju Nair commented on HBASE-17969: --- Can this be closed as duplicate of HBASE-17110 [~carp84]? > Balance by table using SimpleLoadBalancer could end up imbalance > > > Key: HBASE-17969 > URL: https://issues.apache.org/jira/browse/HBASE-17969 > Project: HBase > Issue Type: Improvement > Components: Balancer >Affects Versions: 1.1.10 >Reporter: Allan Yang >Assignee: Allan Yang >Priority: Major > Attachments: HBASE-17969-branch-1.patch, > HBASE-17969-branch-1.v2.patch, HBASE-17969-branch-1.v3.patch, > HBASE-17969.patch > > > This really happens in our production env. > Here is a example: > Say we have three RS named r1, r2, r3. A table named table1 with 3 regions > distributes on these rs like this: > r1 1 > r2 1 > r3 1 > Each rs have one region, it means table1 is balanced. So balancer will not > run. > If the region on r3 splits, then it becomes: > r1 1 > r2 1 > r3 2 > For table1, in average, each rs will have min=1, max=2 regions. So still it > is balanced, balancer will not run. > Then a region on r3 splits again, the distribution becomes: > r1 1 > r2 1 > r3 3 > In average, each rs will have min=1, max=2 regions. So balancer will run. > For r1 and r2, they have already have min=1 regions. Balancer won't do any > operation on them. > But for r3, it exceed max=3, so balancer will remove one region from r3 and > choose one rs from r1, r2 to move to. > But r1 and r2 have the same load, so balancer will always choose r1 since > servername r1 < r2(alphabet order, sorted by ServerAndLoad's compareTo > method). It is OK for table1 itself. But if every table in the cluster have > similar situations like table1, then the load in the cluster will always be > like r1 > r2 > r3. > So, the solution here is when each rs reach min regions (min=total region / > servers), but there still some region need to move, shuffle the regionservers > before move. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20768) should we bypass the RegionLocationFinder#scheduleFullRefresh execution when master has not initialized
[
https://issues.apache.org/jira/browse/HBASE-20768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819526#comment-16819526
]
Biju Nair commented on HBASE-20768:
---
{noformat}
+ // Do not scheduleFullRefresh at master startup
{noformat}
The comment is from HBASE-16570 and looks like no regression. Can we merge this
change? [~apurtell], [~mdrob]
> should we bypass the RegionLocationFinder#scheduleFullRefresh execution when
> master has not initialized
> ---
>
> Key: HBASE-20768
> URL: https://issues.apache.org/jira/browse/HBASE-20768
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Reporter: chenxu
>Priority: Major
> Attachments: HBASE-20768-master-v1.patch
>
>
> Our KYLIN cluster has about 300K Regions, when master startup, It takes a
> long time to do RegionLocationFinder#scheduleFullRefresh.
> During this period, CUBE cannot be built, because master has not initialized.
> Although we can ignore locality factor through HBASE-18478, but i think it
> would be better if we bypass the RegionLocationFinder#scheduleFullRefresh
> until the master initialized
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22255) Process for gaining access to slack and mailing lists
Evelina Dumitrescu created HBASE-22255: -- Summary: Process for gaining access to slack and mailing lists Key: HBASE-22255 URL: https://issues.apache.org/jira/browse/HBASE-22255 Project: HBase Issue Type: Bug Reporter: Evelina Dumitrescu Hello, In the getting started documentation it is written to email the dev list in order to get access to the slack channel. Unfortunately, as a new user I didn't manage to send the email to the dev and user lists. I checked the mailing lists archive and I couldn't find my emails there. What is the procedure for gaining access to the slack and mailing lists in order to start making contributions? Thank you, Evelina -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21048) Get LogLevel is not working from console in secure environment
[
https://issues.apache.org/jira/browse/HBASE-21048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei-Chiu Chuang updated HBASE-21048:
Attachment: HBASE-21048.branch-1.002.patch
> Get LogLevel is not working from console in secure environment
> --
>
> Key: HBASE-21048
> URL: https://issues.apache.org/jira/browse/HBASE-21048
> Project: HBase
> Issue Type: Bug
>Reporter: Chandra Sekhar
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Labels: security
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21048.001.patch, HBASE-21048.branch-1.001.patch,
> HBASE-21048.branch-1.002.patch, HBASE-21048.master.001.patch,
> HBASE-21048.master.002.patch, HBASE-21048.master.003.patch,
> HBASE-21048.master.004.patch, HBASE-21048.master.005.patch,
> HBASE-21048.master.006.patch, HBASE-21048.master.007.patch,
> HBASE-21048.master.008.patch
>
>
> When we try to get log level of specific package in secure environment,
> getting SocketException.
> {code:java}
> hbase/master/bin# ./hbase org.apache.hadoop.hbase.http.log.LogLevel -getlevel
> host-:16010 org.apache.hadoop.hbase
> Connecting to http://host-:16010/logLevel?log=org.apache.hadoop.hbase
> java.net.SocketException: Unexpected end of file from server
> {code}
> It is trying to connect http instead of https
> code snippet that handling only http in *LogLevel.java*
> {code:java}
> public static void main(String[] args) {
> if (args.length == 3 && "-getlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]);
> return;
> }
> else if (args.length == 4 && "-setlevel".equals(args[0])) {
> process("http://; + args[1] + "/logLevel?log=" + args[2]
> + "=" + args[3]);
> return;
> }
> System.err.println(USAGES);
> System.exit(-1);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819480#comment-16819480
]
Lars Hofhansl commented on HBASE-22235:
---
+1
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 1.2.12, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22254) refactor and improve decommissioning logic
[ https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22254: - Status: Patch Available (was: Open) [~stack] [~Apache9] [~apurtell] do you know who might be knowledgeable/interested in reviewing in this part of the code? Thanks! > refactor and improve decommissioning logic > -- > > Key: HBASE-22254 > URL: https://issues.apache.org/jira/browse/HBASE-22254 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22254.patch > > > Making some changes needed to support better decommissioning on large > clusters and with container mode; to test those and add clarify I moved parts > of decommissioning logic from HMaster, Draining tracker, and ServerManager > into a separate class. > Features added/improvements: > 1) More resilient off-loading; right now off-loading fails for a subset of > regions in case of a single region failure; is never done on master restart, > etc. > 2) Option to kill RS after off-loading (good for container mode HBase, e.g. > on YARN). > 3) Option to specify machine names only to decommission, for the API to be > usable for an external system that doesn't care about HBase server names, or > e.g. multiple RS in containers on the same node. > 4) Option to replace existing decommissioning list instead of adding to it > (the same; to avoid additionally remembering what was previously sent to > HBase). > 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22254) HBase - refactor and improve decommissioning logic
[ https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22254: - Issue Type: Improvement (was: Bug) > HBase - refactor and improve decommissioning logic > -- > > Key: HBASE-22254 > URL: https://issues.apache.org/jira/browse/HBASE-22254 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22254.patch > > > Making some changes needed to support better decommissioning on large > clusters and with container mode; to test those and add clarify I moved parts > of decommissioning logic from HMaster, Draining tracker, and ServerManager > into a separate class. > Features added/improvements: > 1) More resilient off-loading; right now off-loading fails for a subset of > regions in case of a single region failure; is never done on master restart, > etc. > 2) Option to kill RS after off-loading (good for container mode HBase, e.g. > on YARN). > 3) Option to specify machine names only to decommission, for the API to be > usable for an external system that doesn't care about HBase server names, or > e.g. multiple RS in containers on the same node. > 4) Option to replace existing decommissioning list instead of adding to it > (the same; to avoid additionally remembering what was previously sent to > HBase). > 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22254) refactor and improve decommissioning logic
[ https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22254: - Summary: refactor and improve decommissioning logic (was: HBase - refactor and improve decommissioning logic) > refactor and improve decommissioning logic > -- > > Key: HBASE-22254 > URL: https://issues.apache.org/jira/browse/HBASE-22254 > Project: HBase > Issue Type: Improvement >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22254.patch > > > Making some changes needed to support better decommissioning on large > clusters and with container mode; to test those and add clarify I moved parts > of decommissioning logic from HMaster, Draining tracker, and ServerManager > into a separate class. > Features added/improvements: > 1) More resilient off-loading; right now off-loading fails for a subset of > regions in case of a single region failure; is never done on master restart, > etc. > 2) Option to kill RS after off-loading (good for container mode HBase, e.g. > on YARN). > 3) Option to specify machine names only to decommission, for the API to be > usable for an external system that doesn't care about HBase server names, or > e.g. multiple RS in containers on the same node. > 4) Option to replace existing decommissioning list instead of adding to it > (the same; to avoid additionally remembering what was previously sent to > HBase). > 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22254) HBase - refactor and improve decommissioning logic
[ https://issues.apache.org/jira/browse/HBASE-22254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-22254: - Attachment: HBASE-22254.patch > HBase - refactor and improve decommissioning logic > -- > > Key: HBASE-22254 > URL: https://issues.apache.org/jira/browse/HBASE-22254 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Major > Attachments: HBASE-22254.patch > > > Making some changes needed to support better decommissioning on large > clusters and with container mode; to test those and add clarify I moved parts > of decommissioning logic from HMaster, Draining tracker, and ServerManager > into a separate class. > Features added/improvements: > 1) More resilient off-loading; right now off-loading fails for a subset of > regions in case of a single region failure; is never done on master restart, > etc. > 2) Option to kill RS after off-loading (good for container mode HBase, e.g. > on YARN). > 3) Option to specify machine names only to decommission, for the API to be > usable for an external system that doesn't care about HBase server names, or > e.g. multiple RS in containers on the same node. > 4) Option to replace existing decommissioning list instead of adding to it > (the same; to avoid additionally remembering what was previously sent to > HBase). > 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-22254) HBase - refactor and improve decommissioning logic
Sergey Shelukhin created HBASE-22254: Summary: HBase - refactor and improve decommissioning logic Key: HBASE-22254 URL: https://issues.apache.org/jira/browse/HBASE-22254 Project: HBase Issue Type: Bug Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Making some changes needed to support better decommissioning on large clusters and with container mode; to test those and add clarify I moved parts of decommissioning logic from HMaster, Draining tracker, and ServerManager into a separate class. Features added/improvements: 1) More resilient off-loading; right now off-loading fails for a subset of regions in case of a single region failure; is never done on master restart, etc. 2) Option to kill RS after off-loading (good for container mode HBase, e.g. on YARN). 3) Option to specify machine names only to decommission, for the API to be usable for an external system that doesn't care about HBase server names, or e.g. multiple RS in containers on the same node. 4) Option to replace existing decommissioning list instead of adding to it (the same; to avoid additionally remembering what was previously sent to HBase). 5) Tests, comments ;) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-22235:
---
Resolution: Fixed
Fix Version/s: 1.3.5
2.2.1
2.1.5
1.2.12
1.4.10
Status: Resolved (was: Patch Available)
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 1.4.10, 2.3.0, 1.2.12, 2.1.5, 2.2.1, 1.3.5
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-17884) Backport HBASE-16217 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-17884: --- Resolution: Fixed Assignee: Gary Helmling (was: Andrew Purtell) Hadoop Flags: Reviewed Fix Version/s: 1.4.10 Status: Resolved (was: Patch Available) > Backport HBASE-16217 to branch-1 > > > Key: HBASE-17884 > URL: https://issues.apache.org/jira/browse/HBASE-17884 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Gary Helmling >Priority: Major > Fix For: 1.5.0, 1.4.10 > > Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch, > HBASE-17884.branch-1.001.patch > > > The change to add calling user to ObserverContext in HBASE-16217 should also > be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access > control checks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20598) Upgrade to JRuby 9.2
[ https://issues.apache.org/jira/browse/HBASE-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819450#comment-16819450 ] Sakthi commented on HBASE-20598: I think this can be taken forward now, [~jackbearden]. 9.2.x [x: 1-7] versions are available now. > Upgrade to JRuby 9.2 > > > Key: HBASE-20598 > URL: https://issues.apache.org/jira/browse/HBASE-20598 > Project: HBase > Issue Type: Bug > Components: dependencies, shell >Reporter: Josh Elser >Assignee: Jack Bearden >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20598.001.patch, HBASE-20598.002.patch > > > [~mdrob] pointed out that there's a JRuby 9.2 release. We should see if we > can get ourselves onto that from our current 9.1 release line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819451#comment-16819451
]
Andrew Purtell commented on HBASE-22235:
Not sure what happened in precommit but these patches are super simple and
ready to go
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-17884) Backport HBASE-16217 to branch-1
[
https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819442#comment-16819442
]
HBase QA commented on HBASE-17884:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
29s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
1s{color} | {color:blue} Findbugs executables are not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} The patch doesn't appear to include any new or
modified tests. Please justify why no new tests are needed for this patch. Also
please list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 23m
31s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
26s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
3s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
8s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
27s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
16s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
56s{color} | {color:green} branch-1 passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
5s{color} | {color:green} branch-1 passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 3m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
1s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
12s{color} | {color:green} the patch passed with JDK v1.7.0_211 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
12s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
41s{color} | {color:red} hbase-server: The patch generated 3 new + 731
unchanged - 58 fixed = 734 total (was 789) {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
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}
1m 53s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
50s{color} | {color:green} the patch passed with JDK v1.8.0_202 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
10s{color} | {color:green} the patch passed with JDK v1.7.0_211 {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
36s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}115m 28s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 3m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} |
[jira] [Commented] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader
[
https://issues.apache.org/jira/browse/HBASE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819413#comment-16819413
]
Esteban Gutierrez commented on HBASE-22253:
---
bq. related: if we are leader and the leader znode is deleted we should step
down
Yeah, probably we should make sure that the session timeout for the keymaster
znode is shorter than the sleep interval for the LeaderElector.
> An AuthenticationTokenSecretManager leader won't step down if another RS
> claims to be a leader
> --
>
> Key: HBASE-22253
> URL: https://issues.apache.org/jira/browse/HBASE-22253
> Project: HBase
> Issue Type: Bug
> Components: security
>Affects Versions: 3.0.0, 2.1.0, 2.2.0
>Reporter: Esteban Gutierrez
>Assignee: Esteban Gutierrez
>Priority: Critical
>
> We ran into a situation were a rogue Lily HBase Indexer [SEP
> Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
> sharing the same {{zookeeper.znode.parent}} claimed to be
> AuthenticationTokenSecretManager for an HBase cluster. This situation
> undesirable since the leader running on the HBase cluster doesn't steps down
> when the rogue leader registers in the HBase cluster and both will start
> rolling keys with the same IDs causing authentication errors. Even a
> reasonable "fix" is to point to a different {{zookeeper.znode.parent}}, we
> should make sure that we step down as leader correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader
[
https://issues.apache.org/jira/browse/HBASE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Esteban Gutierrez reassigned HBASE-22253:
-
Assignee: Esteban Gutierrez
> An AuthenticationTokenSecretManager leader won't step down if another RS
> claims to be a leader
> --
>
> Key: HBASE-22253
> URL: https://issues.apache.org/jira/browse/HBASE-22253
> Project: HBase
> Issue Type: Bug
> Components: security
>Affects Versions: 3.0.0, 2.1.0, 2.2.0
>Reporter: Esteban Gutierrez
>Assignee: Esteban Gutierrez
>Priority: Critical
>
> We ran into a situation were a rogue Lily HBase Indexer [SEP
> Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
> sharing the same {{zookeeper.znode.parent}} claimed to be
> AuthenticationTokenSecretManager for an HBase cluster. This situation
> undesirable since the leader running on the HBase cluster doesn't steps down
> when the rogue leader registers in the HBase cluster and both will start
> rolling keys with the same IDs causing authentication errors. Even a
> reasonable "fix" is to point to a different {{zookeeper.znode.parent}}, we
> should make sure that we step down as leader correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader
[
https://issues.apache.org/jira/browse/HBASE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Esteban Gutierrez updated HBASE-22253:
--
Description:
We ran into a situation were a rogue Lily HBase Indexer [SEP
Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
sharing the same {{zookeeper.znode.parent}} claimed to be
AuthenticationTokenSecretManager for an HBase cluster. This situation
undesirable since the leader running on the HBase cluster doesn't steps down
when the rogue leader registers in the HBase cluster and both will start
rolling keys with the same IDs causing authentication errors. Even a reasonable
"fix" is to point to a different {{zookeeper.znode.parent}}, we should make
sure that we step down as leader correctly.
was:
We ran into a situation were a rouge Lily HBase Indexer [SEP
Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
sharing the same {{zookeeper.znode.parent}} claimed to be
AuthenticationTokenSecretManager for an HBase cluster. This situation
undesirable since the leader running on the HBase cluster doesn't steps down
when the rogue leader registers in the HBase cluster and both will start
rolling keys with the same IDs causing authentication errors. Even a reasonable
"fix" is to point to a different {{zookeeper.znode.parent}}, we should make
sure that we step down as leader correctly.
> An AuthenticationTokenSecretManager leader won't step down if another RS
> claims to be a leader
> --
>
> Key: HBASE-22253
> URL: https://issues.apache.org/jira/browse/HBASE-22253
> Project: HBase
> Issue Type: Bug
> Components: security
>Affects Versions: 3.0.0, 2.1.0, 2.2.0
>Reporter: Esteban Gutierrez
>Priority: Critical
>
> We ran into a situation were a rogue Lily HBase Indexer [SEP
> Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
> sharing the same {{zookeeper.znode.parent}} claimed to be
> AuthenticationTokenSecretManager for an HBase cluster. This situation
> undesirable since the leader running on the HBase cluster doesn't steps down
> when the rogue leader registers in the HBase cluster and both will start
> rolling keys with the same IDs causing authentication errors. Even a
> reasonable "fix" is to point to a different {{zookeeper.znode.parent}}, we
> should make sure that we step down as leader correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader
[
https://issues.apache.org/jira/browse/HBASE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Esteban Gutierrez updated HBASE-22253:
--
Description:
We ran into a situation were a rouge Lily HBase Indexer [SEP
Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
sharing the same {{zookeeper.znode.parent}} claimed to be
AuthenticationTokenSecretManager for an HBase cluster. This situation
undesirable since the leader running on the HBase cluster doesn't steps down
when the rogue leader registers in the HBase cluster and both will start
rolling keys with the same IDs causing authentication errors. Even a reasonable
"fix" is to point to a different {{zookeeper.znode.parent}}, we should make
sure that we step down as leader correctly.
was:
We ran into a situation were a rouge Lily HBase Indexer [SEP
Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
sharing the same {{zookeeper.znode.parent}} claimed to be
AuthenticationTokenSecretManager for an HBase cluster. This situation
undesirable since the leader running on the HBase cluster doesn't steps down
when the rouge leader registers in the HBase cluster and both will start
rolling keys with the same IDs causing authentication errors. Even a reasonable
"fix" is to point to a different {{zookeeper.znode.parent}}, we should make
sure that we step down as leader correctly.
> An AuthenticationTokenSecretManager leader won't step down if another RS
> claims to be a leader
> --
>
> Key: HBASE-22253
> URL: https://issues.apache.org/jira/browse/HBASE-22253
> Project: HBase
> Issue Type: Bug
> Components: security
>Affects Versions: 3.0.0, 2.1.0, 2.2.0
>Reporter: Esteban Gutierrez
>Priority: Critical
>
> We ran into a situation were a rouge Lily HBase Indexer [SEP
> Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
> sharing the same {{zookeeper.znode.parent}} claimed to be
> AuthenticationTokenSecretManager for an HBase cluster. This situation
> undesirable since the leader running on the HBase cluster doesn't steps down
> when the rogue leader registers in the HBase cluster and both will start
> rolling keys with the same IDs causing authentication errors. Even a
> reasonable "fix" is to point to a different {{zookeeper.znode.parent}}, we
> should make sure that we step down as leader correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader
[
https://issues.apache.org/jira/browse/HBASE-22253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819407#comment-16819407
]
Sean Busbey commented on HBASE-22253:
-
related: if we are leader and the leader znode is deleted we should step down
> An AuthenticationTokenSecretManager leader won't step down if another RS
> claims to be a leader
> --
>
> Key: HBASE-22253
> URL: https://issues.apache.org/jira/browse/HBASE-22253
> Project: HBase
> Issue Type: Bug
> Components: security
>Affects Versions: 3.0.0, 2.1.0, 2.2.0
>Reporter: Esteban Gutierrez
>Priority: Critical
>
> We ran into a situation were a rouge Lily HBase Indexer [SEP
> Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
> sharing the same {{zookeeper.znode.parent}} claimed to be
> AuthenticationTokenSecretManager for an HBase cluster. This situation
> undesirable since the leader running on the HBase cluster doesn't steps down
> when the rouge leader registers in the HBase cluster and both will start
> rolling keys with the same IDs causing authentication errors. Even a
> reasonable "fix" is to point to a different {{zookeeper.znode.parent}}, we
> should make sure that we step down as leader correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-22253) An AuthenticationTokenSecretManager leader won't step down if another RS claims to be a leader
Esteban Gutierrez created HBASE-22253:
-
Summary: An AuthenticationTokenSecretManager leader won't step
down if another RS claims to be a leader
Key: HBASE-22253
URL: https://issues.apache.org/jira/browse/HBASE-22253
Project: HBase
Issue Type: Bug
Components: security
Affects Versions: 2.1.0, 3.0.0, 2.2.0
Reporter: Esteban Gutierrez
We ran into a situation were a rouge Lily HBase Indexer [SEP
Consumer|https://github.com/NGDATA/hbase-indexer/blob/master/hbase-sep/hbase-sep-impl/src/main/java/com/ngdata/sep/impl/SepConsumer.java#L169]
sharing the same {{zookeeper.znode.parent}} claimed to be
AuthenticationTokenSecretManager for an HBase cluster. This situation
undesirable since the leader running on the HBase cluster doesn't steps down
when the rouge leader registers in the HBase cluster and both will start
rolling keys with the same IDs causing authentication errors. Even a reasonable
"fix" is to point to a different {{zookeeper.znode.parent}}, we should make
sure that we step down as leader correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819394#comment-16819394
]
HBase QA commented on HBASE-22235:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-22235 does not apply to master. Rebase required? Wrong
Branch? See
https://yetus.apache.org/documentation/in-progress/precommit-patchnames for
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-22235 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12966127/HBASE-22235.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/100/console |
| Powered by | Apache Yetus 0.9.0 http://yetus.apache.org |
This message was automatically generated.
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819391#comment-16819391
]
Andrew Purtell commented on HBASE-22235:
Updated master patch with missing 'public' keywords
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-22235:
---
Attachment: HBASE-22235.patch
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch, HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819389#comment-16819389
]
Lars Hofhansl edited comment on HBASE-22235 at 4/16/19 6:42 PM:
The constants need to be the public in OperationStatus, which you have in the
branch-1 patch but not the master patch - perhaps I'm missing something in the
master branch...?
was (Author: lhofhansl):
The constants need to be the public in OperationStatus.
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819389#comment-16819389
]
Lars Hofhansl commented on HBASE-22235:
---
The constants need to be the public in OperationStatus.
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] HorizonNet commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8
HorizonNet commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8 URL: https://github.com/apache/hbase/pull/136#issuecomment-483789392 Updated the PR to fix the Checkstyle issue. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-21957) Unify refCount of BucketEntry and refCount of hbase.nio.ByteBuff into one
[
https://issues.apache.org/jira/browse/HBASE-21957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819369#comment-16819369
]
HBase QA commented on HBASE-21957:
--
| (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:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 9 new or modified test
files. {color} |
|| || || || {color:brown} HBASE-21879 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
19s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
10s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
41s{color} | {color:green} HBASE-21879 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 3m
35s{color} | {color:blue} hbase-server in HBASE-21879 has 11 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
48s{color} | {color:green} HBASE-21879 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
23s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
59s{color} | {color:green} hbase-server generated 0 new + 6 unchanged - 2 fixed
= 6 total (was 8) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
27s{color} | {color:green} The patch passed checkstyle in hbase-common {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} hbase-server: The patch generated 0 new + 136
unchanged - 7 fixed = 136 total (was 143) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
47s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
8m 59s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
34s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}146m 47s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
43s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}194m 16s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestAsyncTableGetMultiThreaded |
| | hadoop.hbase.quotas.TestClusterScopeQuotaThrottle |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce base:
[GitHub] [hbase] Apache-HBase commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8
Apache-HBase commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8 URL: https://github.com/apache/hbase/pull/136#issuecomment-483785662 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 23 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 4 new or modified test files. | ||| _ master Compile Tests _ | | 0 | mvndep | 145 | Maven dependency ordering for branch | | +1 | mvninstall | 251 | master passed | | +1 | compile | 130 | master passed | | +1 | checkstyle | 115 | master passed | | +1 | shadedjars | 266 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 315 | master passed | | +1 | javadoc | 88 | master passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 16 | Maven dependency ordering for patch | | +1 | mvninstall | 245 | the patch passed | | +1 | compile | 128 | the patch passed | | +1 | javac | 128 | the patch passed | | -1 | checkstyle | 13 | hbase-examples: The patch generated 1 new + 8 unchanged - 0 fixed = 9 total (was 8) | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 263 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 500 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 352 | the patch passed | | +1 | javadoc | 87 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 7047 | hbase-server in the patch passed. | | -1 | unit | 889 | hbase-mapreduce in the patch failed. | | +1 | unit | 270 | hbase-rest in the patch passed. | | +1 | unit | 107 | hbase-examples in the patch passed. | | +1 | asflicense | 87 | The patch does not generate ASF License warnings. | | | | 11574 | | | Reason | Tests | |---:|:--| | Failed junit tests | hadoop.hbase.snapshot.TestExportSnapshotNoCluster | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/4/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/136 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 32fe8b027544 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 20f72f5e25 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | checkstyle | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/4/artifact/out/diff-checkstyle-hbase-examples.txt | | unit | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/4/artifact/out/patch-unit-hbase-mapreduce.txt | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/4/testReport/ | | Max. process+thread count | 5401 (vs. ulimit of 1) | | modules | C: hbase-server hbase-mapreduce hbase-rest hbase-examples U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-136/4/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-17884) Backport HBASE-16217 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819352#comment-16819352 ] Gary Helmling commented on HBASE-17884: --- FWIW, +1 from me. > Backport HBASE-16217 to branch-1 > > > Key: HBASE-17884 > URL: https://issues.apache.org/jira/browse/HBASE-17884 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch, > HBASE-17884.branch-1.001.patch > > > The change to add calling user to ObserverContext in HBASE-16217 should also > be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access > control checks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21284) Forward port HBASE-21000 to branch-2
[
https://issues.apache.org/jira/browse/HBASE-21284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819338#comment-16819338
]
Mingliang Liu commented on HBASE-21284:
---
[~stack] The patch can apply cleanly to {{branch-2}} and {{master}} - if this
is still targeting there. Thanks!
> Forward port HBASE-21000 to branch-2
>
>
> Key: HBASE-21284
> URL: https://issues.apache.org/jira/browse/HBASE-21284
> Project: HBase
> Issue Type: Sub-task
>Reporter: Andrew Purtell
>Assignee: Mingliang Liu
>Priority: Major
> Attachments: HBASE-21284.001.patch
>
>
> See parent for details.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #158: HBASE-22047 LeaseException in Scan should be retried
Apache-HBase commented on issue #158: HBASE-22047 LeaseException in Scan should be retried URL: https://github.com/apache/hbase/pull/158#issuecomment-483773728 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 46 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | -0 | test4tests | 0 | 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. | ||| _ master Compile Tests _ | | +1 | mvninstall | 245 | master passed | | +1 | compile | 25 | master passed | | +1 | checkstyle | 33 | master passed | | +1 | shadedjars | 270 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 59 | master passed | | +1 | javadoc | 23 | master passed | ||| _ Patch Compile Tests _ | | +1 | mvninstall | 244 | the patch passed | | +1 | compile | 24 | the patch passed | | +1 | javac | 24 | the patch passed | | +1 | checkstyle | 29 | the patch passed | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 264 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 481 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 68 | the patch passed | | +1 | javadoc | 21 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 187 | hbase-client in the patch passed. | | +1 | asflicense | 10 | The patch does not generate ASF License warnings. | | | | 2101 | | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-158/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/158 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 4b9909d106ea 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 20f72f5e25 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-158/1/testReport/ | | Max. process+thread count | 312 (vs. ulimit of 1) | | modules | C: hbase-client U: hbase-client | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-158/1/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
[
https://issues.apache.org/jira/browse/HBASE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819325#comment-16819325
]
Andrew Purtell commented on HBASE-22249:
No need, thanks
> HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
> -
>
> Key: HBASE-22249
> URL: https://issues.apache.org/jira/browse/HBASE-22249
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.5
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22249.branch-2.1.001.patch
>
>
> While starting the rest server multiple instances of the following error can
> be seen:
> {code:java}
> java.lang.NoClassDefFoundError: javax/activation/DataSource
> {code}
> After start-up of the server, while serving requests, following errors can be
> seen:
> {code:java}
> Caused by: A MultiException has 3 exceptions. They are:
> 1. java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
> 2. java.lang.IllegalStateException: Unable to perform operation: create on
> org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
> 3. java.lang.IllegalStateException: Unable to perform operation: create on
> org.glassfish.jersey.internal.ContextResolverFactory
> {code}
> And the requests failed like this:
> {code:java}
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Request failed.
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #157: HBASE-16002 Made constructors of DataType subclasses public
Apache-HBase commented on issue #157: HBASE-16002 Made constructors of DataType subclasses public URL: https://github.com/apache/hbase/pull/157#issuecomment-483767513 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 46 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | -0 | test4tests | 0 | 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. | ||| _ master Compile Tests _ | | +1 | mvninstall | 298 | master passed | | +1 | compile | 22 | master passed | | +1 | checkstyle | 22 | master passed | | +1 | shadedjars | 284 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 40 | master passed | | +1 | javadoc | 21 | master passed | ||| _ Patch Compile Tests _ | | +1 | mvninstall | 251 | the patch passed | | +1 | compile | 22 | the patch passed | | +1 | javac | 22 | the patch passed | | +1 | checkstyle | 22 | the patch passed | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 272 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 546 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 49 | the patch passed | | +1 | javadoc | 19 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 163 | hbase-common in the patch passed. | | +1 | asflicense | 12 | The patch does not generate ASF License warnings. | | | | 2162 | | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-157/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/157 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 3ad0d54eeed9 4.4.0-137-generic #163-Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 20f72f5e25 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-157/1/testReport/ | | Max. process+thread count | 288 (vs. ulimit of 1) | | modules | C: hbase-common U: hbase-common | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-157/1/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
[
https://issues.apache.org/jira/browse/HBASE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819294#comment-16819294
]
Sakthi commented on HBASE-22249:
Sure [~apurtell]. Should have kept in mind. I think master needs
"javax.annotation" dependency as well. Shall I open another Jira, in that case,
if applicable?
> HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
> -
>
> Key: HBASE-22249
> URL: https://issues.apache.org/jira/browse/HBASE-22249
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.5
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22249.branch-2.1.001.patch
>
>
> While starting the rest server multiple instances of the following error can
> be seen:
> {code:java}
> java.lang.NoClassDefFoundError: javax/activation/DataSource
> {code}
> After start-up of the server, while serving requests, following errors can be
> seen:
> {code:java}
> Caused by: A MultiException has 3 exceptions. They are:
> 1. java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
> 2. java.lang.IllegalStateException: Unable to perform operation: create on
> org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
> 3. java.lang.IllegalStateException: Unable to perform operation: create on
> org.glassfish.jersey.internal.ContextResolverFactory
> {code}
> And the requests failed like this:
> {code:java}
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Request failed.
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
[
https://issues.apache.org/jira/browse/HBASE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819290#comment-16819290
]
Andrew Purtell commented on HBASE-22249:
[~jatsakthi] The way we commit things on the project we start with master then
move down, so this change will be applied to master (unless you say it is not
ready yet). Taking a dependency on javax.activation only in hbase-rest looks
fine as a generally applicable change to all branches and that's my intent.
> HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
> -
>
> Key: HBASE-22249
> URL: https://issues.apache.org/jira/browse/HBASE-22249
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.5
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22249.branch-2.1.001.patch
>
>
> While starting the rest server multiple instances of the following error can
> be seen:
> {code:java}
> java.lang.NoClassDefFoundError: javax/activation/DataSource
> {code}
> After start-up of the server, while serving requests, following errors can be
> seen:
> {code:java}
> Caused by: A MultiException has 3 exceptions. They are:
> 1. java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
> 2. java.lang.IllegalStateException: Unable to perform operation: create on
> org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
> 3. java.lang.IllegalStateException: Unable to perform operation: create on
> org.glassfish.jersey.internal.ContextResolverFactory
> {code}
> And the requests failed like this:
> {code:java}
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Request failed.
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
[
https://issues.apache.org/jira/browse/HBASE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819279#comment-16819279
]
Sakthi edited comment on HBASE-22249 at 4/16/19 5:08 PM:
-
Thanks for taking a look [~apurtell]. Will do similar testing for master branch
as well.
was (Author: jatsakthi):
Thanks for taking a look [~apurtell]. Will do similar testing for Master as
well.
> HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
> -
>
> Key: HBASE-22249
> URL: https://issues.apache.org/jira/browse/HBASE-22249
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.5
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22249.branch-2.1.001.patch
>
>
> While starting the rest server multiple instances of the following error can
> be seen:
> {code:java}
> java.lang.NoClassDefFoundError: javax/activation/DataSource
> {code}
> After start-up of the server, while serving requests, following errors can be
> seen:
> {code:java}
> Caused by: A MultiException has 3 exceptions. They are:
> 1. java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
> 2. java.lang.IllegalStateException: Unable to perform operation: create on
> org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
> 3. java.lang.IllegalStateException: Unable to perform operation: create on
> org.glassfish.jersey.internal.ContextResolverFactory
> {code}
> And the requests failed like this:
> {code:java}
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Request failed.
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
[
https://issues.apache.org/jira/browse/HBASE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819279#comment-16819279
]
Sakthi edited comment on HBASE-22249 at 4/16/19 5:08 PM:
-
Thanks for taking a look [~apurtell]. Will do similar testing for Master as
well.
was (Author: jatsakthi):
Thanks for taking a look [~apurtell]
> HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
> -
>
> Key: HBASE-22249
> URL: https://issues.apache.org/jira/browse/HBASE-22249
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.5
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22249.branch-2.1.001.patch
>
>
> While starting the rest server multiple instances of the following error can
> be seen:
> {code:java}
> java.lang.NoClassDefFoundError: javax/activation/DataSource
> {code}
> After start-up of the server, while serving requests, following errors can be
> seen:
> {code:java}
> Caused by: A MultiException has 3 exceptions. They are:
> 1. java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
> 2. java.lang.IllegalStateException: Unable to perform operation: create on
> org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
> 3. java.lang.IllegalStateException: Unable to perform operation: create on
> org.glassfish.jersey.internal.ContextResolverFactory
> {code}
> And the requests failed like this:
> {code:java}
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Request failed.
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #156: HBASE-22248 Removed deprecated CollectionUtils
Apache-HBase commented on issue #156: HBASE-22248 Removed deprecated CollectionUtils URL: https://github.com/apache/hbase/pull/156#issuecomment-483761905 :confetti_ball: **+1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 23 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 0 | The patch does not contain any @author tags. | | -0 | test4tests | 0 | 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. | ||| _ master Compile Tests _ | | 0 | mvndep | 13 | Maven dependency ordering for branch | | +1 | mvninstall | 237 | master passed | | +1 | compile | 35 | master passed | | +1 | checkstyle | 33 | master passed | | +1 | shadedjars | 257 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 61 | master passed | | +1 | javadoc | 31 | master passed | ||| _ Patch Compile Tests _ | | 0 | mvndep | 14 | Maven dependency ordering for patch | | +1 | mvninstall | 256 | the patch passed | | +1 | compile | 36 | the patch passed | | +1 | javac | 36 | the patch passed | | +1 | checkstyle | 32 | the patch passed | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 268 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 517 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 73 | the patch passed | | +1 | javadoc | 34 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 165 | hbase-common in the patch passed. | | +1 | unit | 24 | hbase-metrics in the patch passed. | | +1 | asflicense | 22 | The patch does not generate ASF License warnings. | | | | 2223 | | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-156/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/156 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 46959825c586 4.4.0-139-generic #165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 20f72f5e25 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-156/1/testReport/ | | Max. process+thread count | 315 (vs. ulimit of 1) | | modules | C: hbase-common hbase-metrics U: . | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-156/1/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
[
https://issues.apache.org/jira/browse/HBASE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819279#comment-16819279
]
Sakthi commented on HBASE-22249:
Thanks for taking a look [~apurtell]
> HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
> -
>
> Key: HBASE-22249
> URL: https://issues.apache.org/jira/browse/HBASE-22249
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.5
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22249.branch-2.1.001.patch
>
>
> While starting the rest server multiple instances of the following error can
> be seen:
> {code:java}
> java.lang.NoClassDefFoundError: javax/activation/DataSource
> {code}
> After start-up of the server, while serving requests, following errors can be
> seen:
> {code:java}
> Caused by: A MultiException has 3 exceptions. They are:
> 1. java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
> 2. java.lang.IllegalStateException: Unable to perform operation: create on
> org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
> 3. java.lang.IllegalStateException: Unable to perform operation: create on
> org.glassfish.jersey.internal.ContextResolverFactory
> {code}
> And the requests failed like this:
> {code:java}
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Request failed.
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] hextriclosan opened a new pull request #158: HBASE-22047 LeaseException in Scan should be retried
hextriclosan opened a new pull request #158: HBASE-22047 LeaseException in Scan should be retried URL: https://github.com/apache/hbase/pull/158 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (HBASE-22216) "Waiting on master failover to complete" shows 30 to 40 time per millisecond
[ https://issues.apache.org/jira/browse/HBASE-22216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819266#comment-16819266 ] Andrew Purtell edited comment on HBASE-22216 at 4/16/19 5:03 PM: - [~xucang] [~jain.ankit] is already in the Contributors group so can assign and create JIRAs. Looking forward to the patch for this problem. Let's get it in. Sounds bad. was (Author: apurtell): [~xucang] [~jain.ankit] is already in the Contributors group so can assign and create JIRAs. Looking forward to the patch for this problem. Let's get it it. Sounds bad. > "Waiting on master failover to complete" shows 30 to 40 time per millisecond > - > > Key: HBASE-22216 > URL: https://issues.apache.org/jira/browse/HBASE-22216 > Project: HBase > Issue Type: Bug > Components: logging, Operability, proc-v2 >Affects Versions: 1.3.0 >Reporter: Xu Cang >Assignee: Ankit Jain >Priority: Minor > > "Waiting on master failover to complete" appears 30 to 40 times per > *millisecond* from one host when master is initializing. > This message is too noisy, epecially when there are issues when master init. > Should fix this by either rate-limiting or even revisit is that normal > #executeFromState gets called 30-40 times per ms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22249) HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
[
https://issues.apache.org/jira/browse/HBASE-22249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819275#comment-16819275
]
Andrew Purtell commented on HBASE-22249:
+1
Will commit later today unless objection
> HBase Rest Server throws NoClassDefFoundError with JAVA 11 (run-time)
> -
>
> Key: HBASE-22249
> URL: https://issues.apache.org/jira/browse/HBASE-22249
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.1.5
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Major
> Labels: jdk11
> Attachments: hbase-22249.branch-2.1.001.patch
>
>
> While starting the rest server multiple instances of the following error can
> be seen:
> {code:java}
> java.lang.NoClassDefFoundError: javax/activation/DataSource
> {code}
> After start-up of the server, while serving requests, following errors can be
> seen:
> {code:java}
> Caused by: A MultiException has 3 exceptions. They are:
> 1. java.lang.NoClassDefFoundError: Could not initialize class
> com.sun.xml.bind.v2.model.impl.RuntimeBuiltinLeafInfoImpl
> 2. java.lang.IllegalStateException: Unable to perform operation: create on
> org.apache.hadoop.hbase.rest.provider.JAXBContextResolver
> 3. java.lang.IllegalStateException: Unable to perform operation: create on
> org.glassfish.jersey.internal.ContextResolverFactory
> {code}
> And the requests failed like this:
> {code:java}
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> Request failed.
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22216) "Waiting on master failover to complete" shows 30 to 40 time per millisecond
[ https://issues.apache.org/jira/browse/HBASE-22216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819272#comment-16819272 ] Xu Cang commented on HBASE-22216: - OK thanks [~apurtell] Not sure why he couldn't do it last week. We will double check. > "Waiting on master failover to complete" shows 30 to 40 time per millisecond > - > > Key: HBASE-22216 > URL: https://issues.apache.org/jira/browse/HBASE-22216 > Project: HBase > Issue Type: Bug > Components: logging, Operability, proc-v2 >Affects Versions: 1.3.0 >Reporter: Xu Cang >Assignee: Ankit Jain >Priority: Minor > > "Waiting on master failover to complete" appears 30 to 40 times per > *millisecond* from one host when master is initializing. > This message is too noisy, epecially when there are issues when master init. > Should fix this by either rate-limiting or even revisit is that normal > #executeFromState gets called 30-40 times per ms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22217) HBase shell command proposal : "rit assign all"
[ https://issues.apache.org/jira/browse/HBASE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819268#comment-16819268 ] Sergey Shelukhin commented on HBASE-22217: -- [~xucang] my experience was that sometimes it says that the region is in transition and cannot be assigned, iirc usually when it's CLOSING. I didn't investigate in detail. > HBase shell command proposal : "rit assign all" > > > Key: HBASE-22217 > URL: https://issues.apache.org/jira/browse/HBASE-22217 > Project: HBase > Issue Type: New Feature > Components: Operability, Region Assignment, shell >Reporter: Xu Cang >Assignee: Sakthi >Priority: Minor > > HBase shell command proposal : "rit assign all" > > Currently we have shell command "rit" to list all RITs. > It would be handy having a command "rit assign all" to assign all RITs. > This equals to getting the list of RITs from 'rit' command and running > "assign " one by one. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-22216) "Waiting on master failover to complete" shows 30 to 40 time per millisecond
[ https://issues.apache.org/jira/browse/HBASE-22216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819266#comment-16819266 ] Andrew Purtell commented on HBASE-22216: [~xucang] [~jain.ankit] is already in the Contributors group so can assign and create JIRAs. Looking forward to the patch for this problem. Let's get it it. Sounds bad. > "Waiting on master failover to complete" shows 30 to 40 time per millisecond > - > > Key: HBASE-22216 > URL: https://issues.apache.org/jira/browse/HBASE-22216 > Project: HBase > Issue Type: Bug > Components: logging, Operability, proc-v2 >Affects Versions: 1.3.0 >Reporter: Xu Cang >Assignee: Ankit Jain >Priority: Minor > > "Waiting on master failover to complete" appears 30 to 40 times per > *millisecond* from one host when master is initializing. > This message is too noisy, epecially when there are issues when master init. > Should fix this by either rate-limiting or even revisit is that normal > #executeFromState gets called 30-40 times per ms. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17884) Backport HBASE-16217 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819262#comment-16819262 ] Andrew Purtell commented on HBASE-17884: Going to commit this later today unless objection > Backport HBASE-16217 to branch-1 > > > Key: HBASE-17884 > URL: https://issues.apache.org/jira/browse/HBASE-17884 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch, > HBASE-17884.branch-1.001.patch > > > The change to add calling user to ObserverContext in HBASE-16217 should also > be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access > control checks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-17884) Backport HBASE-16217 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-17884: --- Attachment: HBASE-17884-branch-1.patch > Backport HBASE-16217 to branch-1 > > > Key: HBASE-17884 > URL: https://issues.apache.org/jira/browse/HBASE-17884 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors, security >Reporter: Gary Helmling >Assignee: Andrew Purtell >Priority: Major > Fix For: 1.5.0 > > Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch, > HBASE-17884.branch-1.001.patch > > > The change to add calling user to ObserverContext in HBASE-16217 should also > be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access > control checks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-17884) Backport HBASE-16217 to branch-1
[
https://issues.apache.org/jira/browse/HBASE-17884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819261#comment-16819261
]
Andrew Purtell commented on HBASE-17884:
Updated patch fixes checkstyle warnings, except this one:
{quote}AccessController.java:600: private boolean checkCoveringPermission(User
user, OpType request, RegionCoprocessorEnvironment e,:3: Method length is 166
lines (max allowed is 150). [MethodLength]{quote}
This is not due to this patch and is not an easy change. Leaving it in place.
> Backport HBASE-16217 to branch-1
>
>
> Key: HBASE-17884
> URL: https://issues.apache.org/jira/browse/HBASE-17884
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors, security
>Reporter: Gary Helmling
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-17884-branch-1.patch, HBASE-17884-branch-1.patch,
> HBASE-17884.branch-1.001.patch
>
>
> The change to add calling user to ObserverContext in HBASE-16217 should also
> be applied to branch-1 to avoid use of UserGroupInformation.doAs() for access
> control checks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22217) HBase shell command proposal : "rit assign all"
[ https://issues.apache.org/jira/browse/HBASE-22217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819254#comment-16819254 ] Sakthi commented on HBASE-22217: Are we planning to add this in hbase as of now ? or hbck2? > HBase shell command proposal : "rit assign all" > > > Key: HBASE-22217 > URL: https://issues.apache.org/jira/browse/HBASE-22217 > Project: HBase > Issue Type: New Feature > Components: Operability, Region Assignment, shell >Reporter: Xu Cang >Assignee: Sakthi >Priority: Minor > > HBase shell command proposal : "rit assign all" > > Currently we have shell command "rit" to list all RITs. > It would be handy having a command "rit assign all" to assign all RITs. > This equals to getting the list of RITs from 'rit' command and running > "assign " one by one. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-16002) Many DataType constructors are not public
[
https://issues.apache.org/jira/browse/HBASE-16002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819250#comment-16819250
]
Jan Hentschel commented on HBASE-16002:
---
[~ndimiduk] Thanks for the feedback. I rebased the patch and created a PR for
it.
> Many DataType constructors are not public
> -
>
> Key: HBASE-16002
> URL: https://issues.apache.org/jira/browse/HBASE-16002
> Project: HBase
> Issue Type: Bug
>Reporter: Nick Dimiduk
>Assignee: Jan Hentschel
>Priority: Major
> Attachments: HBASE-16002.master.001.patch
>
>
> Using the {{Struct}} class to build a rowkey, I noticed than many of the
> provided {{DataType}} implementations' constructors are protected. They
> should be public in most (all?) cases.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22206) dist.apache.org must not be used for public downloads
[ https://issues.apache.org/jira/browse/HBASE-22206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819249#comment-16819249 ] Dima Spivak commented on HBASE-22206: - Fine by me, I'll keep an eye on HBASE-2 until then. Thanks for the heads up, [~busbey]. > dist.apache.org must not be used for public downloads > - > > Key: HBASE-22206 > URL: https://issues.apache.org/jira/browse/HBASE-22206 > Project: HBase > Issue Type: Bug > Components: website >Reporter: Sebb >Assignee: Dima Spivak >Priority: Major > Attachments: HBASE-22206.master.001.patch, > HBASE-22206.master.001.patch > > > The dist.apache.org server is only intended for use by developers in staging > releases. > It must not be used on public download pages. > Please use www.apache.org/dist (for KEYS, hashes and sigs) and the mirror > system instead. > The current download page has lots of references to dist.a.o; please replace > thes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] HorizonNet opened a new pull request #157: HBASE-16002 Made constructors of DataType subclasses public
HorizonNet opened a new pull request #157: HBASE-16002 Made constructors of DataType subclasses public URL: https://github.com/apache/hbase/pull/157 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819242#comment-16819242
]
Andrew Purtell commented on HBASE-22235:
Precommit passed.
[~lhofhansl] you wanted this, right? Please +1
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-22235) OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party coprocessors
[
https://issues.apache.org/jira/browse/HBASE-22235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819242#comment-16819242
]
Andrew Purtell edited comment on HBASE-22235 at 4/16/19 4:40 PM:
-
Precommit passed.
[~lhofhansl] you wanted this, right? Please review
was (Author: apurtell):
Precommit passed.
[~lhofhansl] you wanted this, right? Please +1
> OperationStatus.{SUCCESS|FAILURE|NOT_RUN} are not visible to 3rd party
> coprocessors
> ---
>
> Key: HBASE-22235
> URL: https://issues.apache.org/jira/browse/HBASE-22235
> Project: HBase
> Issue Type: Bug
> Components: Coprocessors
>Reporter: Lars Hofhansl
>Assignee: Andrew Purtell
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.3.0
>
> Attachments: HBASE-22235-branch-1.patch, HBASE-22235.patch,
> HBASE-22235.patch
>
>
> preBatchMutate is useless for some operation due to this.
> See also TEPHRA-299. This looks like an oversight.
> MiniBatchOperationInProgress has limited visibility for coprocessors.
> OperationStatus and OperationStatusCode should have the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-22200) WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
[
https://issues.apache.org/jira/browse/HBASE-22200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819239#comment-16819239
]
Zach York commented on HBASE-22200:
---
+1
I agree we shouldn't disable the filesystem cache unless we need to (we would
have an overhead for each FileSystem instance we need to construct).
I will commit now. Are Master and branch-2.1 the only ones affected?
> WALSplitter.hasRecoveredEdits should use same FS instance from WAL region dir
> -
>
> Key: HBASE-22200
> URL: https://issues.apache.org/jira/browse/HBASE-22200
> Project: HBase
> Issue Type: Bug
>Reporter: Wellington Chevreuil
>Assignee: Wellington Chevreuil
>Priority: Major
> Labels: S3, WAL
> Attachments: HBASE-22200-branch-2.1-001.patch,
> HBASE-22200-branch-2.1-002.patch, HBASE-22200-branch-2.1-003.patch,
> HBASE-22200-master-001.patch, HBASE-22200-master-002.patch
>
>
> *WALSplitter.hasRecoveredEdits* should use same FS instance from WAL region
> dir when checking for recovered.edits files, instead of taking FS instance as
> additional method parameter. When specifying different file systems for *wal
> dir* and *root dir*, *WALSplitter.hasRecoveredEdits* current implementation
> will crash or give wrong results. As of now, it's being used indirectly by
> *SplitTableRegionProcedure*. When running tests with *WAL dir* on HDFS and
> *root dir* on S3, for example, noticed region split failing with below error:
> {noformat}
> 2019-04-08 13:53:58,064 ERROR
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor: CODE-BUG: Uncaught
> runtime exception: pid=98,
> state=RUNNABLE:SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS, locked=true;
> SplitTableRegionProcedure table=test-tbl,
> parent=4c5db01611e97e3abbe02e781e867212,
> daughterA=28a0a5e4ef7618899f6bd6dfb5335fe7,
> daughterB=05fa26feaf03ebf9e87e099cbd1eabac
> java.lang.IllegalArgumentException: Path
> hdfs://host-1.example.com:8020/wal_dir/default/test-tbl/4c5db01611e97e3abbe02e781e867212/recovered.edits
> scheme must be s3a
> at
> com.google.common.base.Preconditions.checkArgument(Preconditions.java:115)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.checkPath(DynamoDBMetadataStore.java:1127)
> at
> org.apache.hadoop.fs.s3a.s3guard.DynamoDBMetadataStore.get(DynamoDBMetadataStore.java:437)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.innerGetFileStatus(S3AFileSystem.java:2110)
> at
> org.apache.hadoop.fs.s3a.S3AFileSystem.getFileStatus(S3AFileSystem.java:2088)
> at
> org.apache.hadoop.fs.FilterFileSystem.getFileStatus(FilterFileSystem.java:442)
> at org.apache.hadoop.fs.FileSystem.exists(FileSystem.java:1668)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.getSplitEditFilesSorted(WALSplitter.java:576)
> at
> org.apache.hadoop.hbase.wal.WALSplitter.hasRecoveredEdits(WALSplitter.java:558)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.hasRecoveredEdits(SplitTableRegionProcedure.java:148)
> at
> org.apache.hadoop.hbase.master.assignment.SplitTableRegionProcedure.executeFromState(SplitTableRegionProcedure.java:255)
> {noformat}
> Since *WALSplitter.hasRecoveredEdits* already resolves the proper WAL dir for
> the region, we can simply re-use FS instance from the path instance for the
> WAL dir region, when searching for recovered.edits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [hbase] anis016 opened a new pull request #156: HBASE-22248 Removed deprecated CollectionUtils
anis016 opened a new pull request #156: HBASE-22248 Removed deprecated CollectionUtils URL: https://github.com/apache/hbase/pull/156 Removed deprecated CollectionUtils and the required dependencies. Fixes: [HBASE-22248](https://issues.apache.org/jira/browse/HBASE-22248) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (HBASE-22248) Remove deprecated CollectionUtils
[ https://issues.apache.org/jira/browse/HBASE-22248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sayed Anisul Hoque reassigned HBASE-22248: -- Assignee: Sayed Anisul Hoque > Remove deprecated CollectionUtils > - > > Key: HBASE-22248 > URL: https://issues.apache.org/jira/browse/HBASE-22248 > Project: HBase > Issue Type: Task >Reporter: Jan Hentschel >Assignee: Sayed Anisul Hoque >Priority: Minor > > The class CollectionUtils was deprecated and should be removed in 3.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-22248) Remove deprecated CollectionUtils
[ https://issues.apache.org/jira/browse/HBASE-22248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-22248 started by Sayed Anisul Hoque. -- > Remove deprecated CollectionUtils > - > > Key: HBASE-22248 > URL: https://issues.apache.org/jira/browse/HBASE-22248 > Project: HBase > Issue Type: Task >Reporter: Jan Hentschel >Assignee: Sayed Anisul Hoque >Priority: Minor > > The class CollectionUtils was deprecated and should be removed in 3.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-22247) Remove deprecated field from MetricsReplicationSourceSourceImpl
[ https://issues.apache.org/jira/browse/HBASE-22247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Hentschel resolved HBASE-22247. --- Resolution: Duplicate Should be already included in HBASE-22247. > Remove deprecated field from MetricsReplicationSourceSourceImpl > --- > > Key: HBASE-22247 > URL: https://issues.apache.org/jira/browse/HBASE-22247 > Project: HBase > Issue Type: Task >Reporter: Jan Hentschel >Assignee: Sayed Anisul Hoque >Priority: Trivial > > The field shippedKBsKey of the class MetricsReplicationSourceSourceImpl was > deprecated in 1.3.0 and should be removed for 3.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (HBASE-22247) Remove deprecated field from MetricsReplicationSourceSourceImpl
[ https://issues.apache.org/jira/browse/HBASE-22247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sayed Anisul Hoque reassigned HBASE-22247: -- Assignee: Sayed Anisul Hoque > Remove deprecated field from MetricsReplicationSourceSourceImpl > --- > > Key: HBASE-22247 > URL: https://issues.apache.org/jira/browse/HBASE-22247 > Project: HBase > Issue Type: Task >Reporter: Jan Hentschel >Assignee: Sayed Anisul Hoque >Priority: Trivial > > The field shippedKBsKey of the class MetricsReplicationSourceSourceImpl was > deprecated in 1.3.0 and should be removed for 3.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (HBASE-22246) Remove deprecated field from MetricsReplicationSourceSource
[ https://issues.apache.org/jira/browse/HBASE-22246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-22246 started by Sayed Anisul Hoque. -- > Remove deprecated field from MetricsReplicationSourceSource > --- > > Key: HBASE-22246 > URL: https://issues.apache.org/jira/browse/HBASE-22246 > Project: HBase > Issue Type: Task >Reporter: Jan Hentschel >Assignee: Sayed Anisul Hoque >Priority: Trivial > > The field SOURCE_SHIPPED_KBS in the class MetricsReplicationSourceSource is > deprecated and should be removed in 3.0.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] Apache-HBase commented on issue #155: HBASE-22244 Make use of MetricsConnection in async client
Apache-HBase commented on issue #155: HBASE-22244 Make use of MetricsConnection in async client URL: https://github.com/apache/hbase/pull/155#issuecomment-483702634 :broken_heart: **-1 overall** | Vote | Subsystem | Runtime | Comment | |::|--:|:|:| | 0 | reexec | 20 | Docker mode activated. | ||| _ Prechecks _ | | +1 | hbaseanti | 0 | Patch does not have any anti-patterns. | | +1 | @author | 1 | The patch does not contain any @author tags. | | +1 | test4tests | 0 | The patch appears to include 1 new or modified test files. | ||| _ master Compile Tests _ | | +1 | mvninstall | 270 | master passed | | +1 | compile | 25 | master passed | | +1 | checkstyle | 34 | master passed | | +1 | shadedjars | 279 | branch has no errors when building our shaded downstream artifacts. | | +1 | findbugs | 63 | master passed | | +1 | javadoc | 23 | master passed | ||| _ Patch Compile Tests _ | | +1 | mvninstall | 265 | the patch passed | | +1 | compile | 26 | the patch passed | | +1 | javac | 26 | the patch passed | | -1 | checkstyle | 33 | hbase-client: The patch generated 2 new + 17 unchanged - 1 fixed = 19 total (was 18) | | +1 | whitespace | 0 | The patch has no whitespace issues. | | +1 | shadedjars | 281 | patch has no errors when building our shaded downstream artifacts. | | +1 | hadoopcheck | 532 | Patch does not cause any errors with Hadoop 2.7.4 or 3.0.0. | | +1 | findbugs | 80 | the patch passed | | +1 | javadoc | 24 | the patch passed | ||| _ Other Tests _ | | +1 | unit | 206 | hbase-client in the patch passed. | | +1 | asflicense | 12 | The patch does not generate ASF License warnings. | | | | 2232 | | | Subsystem | Report/Notes | |--:|:-| | Docker | Client=17.05.0-ce Server=17.05.0-ce base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-155/1/artifact/out/Dockerfile | | GITHUB PR | https://github.com/apache/hbase/pull/155 | | Optional Tests | dupname asflicense javac javadoc unit findbugs shadedjars hadoopcheck hbaseanti checkstyle compile | | uname | Linux 97870642aa72 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct 31 10:55:11 UTC 2018 x86_64 GNU/Linux | | Build tool | maven | | Personality | /testptch/patchprocess/precommit/personality/provided.sh | | git revision | master / 20f72f5e25 | | maven | version: Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) | | Default Java | 1.8.0_181 | | findbugs | v3.1.11 | | checkstyle | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-155/1/artifact/out/diff-checkstyle-hbase-client.txt | | Test Results | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-155/1/testReport/ | | Max. process+thread count | 262 (vs. ulimit of 1) | | modules | C: hbase-client U: hbase-client | | Console output | https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-155/1/console | | Powered by | Apache Yetus 0.9.0 http://yetus.apache.org | This message was automatically generated. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (HBASE-22199) Replace "UTF-8" with StandardCharsets.UTF_8 where possible
[ https://issues.apache.org/jira/browse/HBASE-22199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819123#comment-16819123 ] Jan Hentschel commented on HBASE-22199: --- Updated the PR accordingly. Thanks [~psomogyi] for the feedback. > Replace "UTF-8" with StandardCharsets.UTF_8 where possible > -- > > Key: HBASE-22199 > URL: https://issues.apache.org/jira/browse/HBASE-22199 > Project: HBase > Issue Type: Task >Reporter: Jan Hentschel >Assignee: Jan Hentschel >Priority: Trivial > > Currently the String "UTF-8" is used in some places where > StandardCharsets.UTF_8 could be used. To make it easier to maintain, the > current usages of "UTF-8" as a String should be replaced with > StandardCharsets.UTF_8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] HorizonNet commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8
HorizonNet commented on issue #136: HBASE-22199 Replaced UTF-8 String with StandardCharsets.UTF_8 URL: https://github.com/apache/hbase/pull/136#issuecomment-483699358 Updated PR according to feedback from @petersomogyi on the Jira ticket. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (HBASE-21957) Unify refCount of BucketEntry and refCount of hbase.nio.ByteBuff into one
[ https://issues.apache.org/jira/browse/HBASE-21957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-21957: - Attachment: HBASE-21957.HBASE-21879.v8.patch > Unify refCount of BucketEntry and refCount of hbase.nio.ByteBuff into one > - > > Key: HBASE-21957 > URL: https://issues.apache.org/jira/browse/HBASE-21957 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu >Priority: Major > Attachments: HBASE-21957.HBASE-21879.v1.patch, > HBASE-21957.HBASE-21879.v2.patch, HBASE-21957.HBASE-21879.v3.patch, > HBASE-21957.HBASE-21879.v4.patch, HBASE-21957.HBASE-21879.v5.patch, > HBASE-21957.HBASE-21879.v6.patch, HBASE-21957.HBASE-21879.v8.patch > > > After HBASE-12295, we have block with MemoryType.SHARED or > MemoryType.EXCLUSIVE, the block in offheap BucketCache will be shared, and > have an reference count to track its life cycle. If no rpc reference to the > shared block, then the block can be evicted. > while after the HBASE-21916, we introduced an refcount for ByteBuff, then I > think we can unify the two into one. tried to fix this when preparing patch > for HBASE-21879, but seems can be different sub-task, and it won't affect the > main logic of HBASE-21879, so create a seperate one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [hbase] Apache9 commented on issue #155: HBASE-22244 Make use of MetricsConnection in async client
Apache9 commented on issue #155: HBASE-22244 Make use of MetricsConnection in async client URL: https://github.com/apache/hbase/pull/155#issuecomment-483686792 The multi related metrics have not been integrated yet. Filed HBASE-22252 to discuss it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
