[jira] [Commented] (HBASE-20388) nightly tests running on a feature branch should only comment on that feature branch's jira

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438588#comment-16438588
 ] 

Hudson commented on HBASE-20388:


Results for branch HBASE-20388
[build #6 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20388/6/]: 
(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-20388/6//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-20388/6//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-20388/6//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> nightly tests running on a feature branch should only comment on that feature 
> branch's jira
> ---
>
> Key: HBASE-20388
> URL: https://issues.apache.org/jira/browse/HBASE-20388
> Project: HBase
>  Issue Type: Improvement
>  Components: community, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20388.0.patch, HBASE-20388.1.patch
>
>
> It would help improve our signal-to-noise ratio from nightly tests if feature 
> branch runs stopped commenting on all the jiras that got covered by a rebase 
> / merge.
> should be straight forward to have the commenting bit check the current 
> branch against our feature branch naming convention.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20416) [DOC] Fix hbck option intros

2018-04-14 Thread Wei-Chiu Chuang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438574#comment-16438574
 ] 

Wei-Chiu Chuang commented on HBASE-20416:
-

Let me take a stab at this. Looks like a good way to learn more about HBase.

> [DOC] Fix hbck option intros
> 
>
> Key: HBASE-20416
> URL: https://issues.apache.org/jira/browse/HBASE-20416
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
>
> {quote}
> In this case, you can use the -fixSplitParents 
> This option should not normally be used, and it is not in -fixAll.
> {quote}
> There is no such option "-fixAll". From the context, it seems to refer to 
> -repair
> In addition, -repair option also covers -fixReferenceFiles, -fixHFileLinks, 
> which are not introduced in the doc.
> {code:title=HBaseFsck#exec}
> else if (cmd.equals("-repair")) {
> // this attempts to merge overlapping hdfs regions, needs testing
> // under load
> setFixHdfsHoles(true);
> setFixHdfsOrphans(true);
> setFixMeta(true);
> setFixAssignments(true);
> setFixHdfsOverlaps(true);
> setFixVersionFile(true);
> setSidelineBigOverlaps(true);
> setFixSplitParents(false);
> setCheckHdfs(true);
> setFixReferenceFiles(true);
> setFixHFileLinks(true);
> {code}
> {quote}
> -repair includes all the region consistency options and only the hole 
> repairing table integrity options.
> {quote}
> ... seems untrue to me.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (HBASE-20416) [DOC] Fix hbck option intros

2018-04-14 Thread Wei-Chiu Chuang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei-Chiu Chuang reassigned HBASE-20416:
---

Assignee: Wei-Chiu Chuang

> [DOC] Fix hbck option intros
> 
>
> Key: HBASE-20416
> URL: https://issues.apache.org/jira/browse/HBASE-20416
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Major
>
> {quote}
> In this case, you can use the -fixSplitParents 
> This option should not normally be used, and it is not in -fixAll.
> {quote}
> There is no such option "-fixAll". From the context, it seems to refer to 
> -repair
> In addition, -repair option also covers -fixReferenceFiles, -fixHFileLinks, 
> which are not introduced in the doc.
> {code:title=HBaseFsck#exec}
> else if (cmd.equals("-repair")) {
> // this attempts to merge overlapping hdfs regions, needs testing
> // under load
> setFixHdfsHoles(true);
> setFixHdfsOrphans(true);
> setFixMeta(true);
> setFixAssignments(true);
> setFixHdfsOverlaps(true);
> setFixVersionFile(true);
> setSidelineBigOverlaps(true);
> setFixSplitParents(false);
> setCheckHdfs(true);
> setFixReferenceFiles(true);
> setFixHFileLinks(true);
> {code}
> {quote}
> -repair includes all the region consistency options and only the hole 
> repairing table integrity options.
> {quote}
> ... seems untrue to me.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20364) nightly job gives old results or no results for stages that timeout on SCM

2018-04-14 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-20364:

   Resolution: Fixed
Fix Version/s: 2.0.1
   1.4.4
   1.3.3
   1.2.7
   1.5.0
   2.1.0
   3.0.0
   Status: Resolved  (was: Patch Available)

> nightly job gives old results or no results for stages that timeout on SCM
> --
>
> Key: HBASE-20364
> URL: https://issues.apache.org/jira/browse/HBASE-20364
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 3.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20364.0.patch
>
>
> seen in the branch-2.0 nightly report for HBASE-18828:
>  
> {quote}
> Results for branch branch-2.0
>  [build #143 on 
> builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/143/]:
>  (x) *\{color:red}-1 overall\{color}*
> 
> details (if available):
> (/) \{color:green}+1 general checks\{color}
> -- For more information [see general 
> report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/140//General_Nightly_Build_Report/]
>  
> (/) \{color:green}+1 jdk8 hadoop2 checks\{color}
> -- For more information [see jdk8 (hadoop2) 
> report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/143//JDK8_Nightly_Build_Report_(Hadoop2)/]
> (/) \{color:green}+1 jdk8 hadoop3 checks\{color}
> -- For more information [see jdk8 (hadoop3) 
> report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/143//JDK8_Nightly_Build_Report_(Hadoop3)/]
>  
> {quote}
>  
> -1 for the overall build was correct. build #143 failed both the general 
> check and the source tarball check.
>  
> but in the posted comment, we get a false "passing" that links to the general 
> result from build #140. and we get no result for the source tarball at all.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20415) branches-2 don't need maven-scala-plugin

2018-04-14 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-20415:

   Resolution: Fixed
Fix Version/s: 2.0.1
   2.1.0
   Status: Resolved  (was: Patch Available)

> branches-2 don't need maven-scala-plugin
> 
>
> Key: HBASE-20415
> URL: https://issues.apache.org/jira/browse/HBASE-20415
> Project: HBase
>  Issue Type: Task
>  Components: build
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 2.1.0, 2.0.1
>
> Attachments: HBASE-20415-branch-2.v0.patch
>
>
> the spark support revert missed a couple of plugins in the top level pom for 
> making sure we get scaladocs.
> verified there is no scala in the source tree, so these plugins aren't needed.
> {code}
> hbase $ find . -name '*.scala'
> hbase $ 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20233) [metrics] Ill-formatted numRegions metric in "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438541#comment-16438541
 ] 

Hudson commented on HBASE-20233:


Results for branch branch-2.0
[build #177 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/177/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/173//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/177//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/177//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> [metrics] Ill-formatted numRegions metric in 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean
> ---
>
> Key: HBASE-20233
> URL: https://issues.apache.org/jira/browse/HBASE-20233
> Project: HBase
>  Issue Type: Bug
>  Components: metrics, Operability
>Reporter: stack
>Assignee: Xu Cang
>Priority: Trivial
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-20233-v1.patch, HBASE-20233.patch
>
>
> Noticed this poking at metrics. The MBean 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" carries per region 
> metrics. They are all formatted like so:
> {code}
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_98th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99.9th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_num_ops:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_min: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_max: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_mean: 
> 0,
> {code}
> In the middle of them all is a metric named...
> {code}
> numRegions: 15,
> {code}
> It has a different format and it is out of scope when compared to the other 
> metrics in this mbean; it belongs better elsewhere, perhaps in the Server 
> bean.
> I noticed it because it breaks the parse done by tcollector scraping our 
> metrics from /jmx
> It was added long ago in HBASE-14166



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438539#comment-16438539
 ] 

Hudson commented on HBASE-20335:


Results for branch branch-1.3
[build #296 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/296/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/291//General_Nightly_Build_Report/]


(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/296//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/296//JDK8_Nightly_Build_Report_(Hadoop2)/]






> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20335.0.patch, HBASE-20335.1.patch
>
>
> something is up with nightly jobs. they no longer have the machine 
> information from HBASE-19228.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (HBASE-20188) [TESTING] Performance

2018-04-14 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438530#comment-16438530
 ] 

stack edited comment on HBASE-20188 at 4/14/18 10:43 PM:
-

In my YCSB runs, comparing 1.2.7 to 2.0.0 loads, I see that we carry more in 
hbase memstores (total.png) but when I look by region, we seem to carry less 
per region and spike sizes more often (perregion.png). See attached graphs (the 
hits.png is so you can see the overall profile of load, mixed, pure-read for 
1.2.7 and then for 2.0.0)


was (Author: stack):
In my YCSB runs, comparing 1.2.7 to 2.0.0 loads, I see that we carry more in 
hbase memstores but when I look by region, we seem to carry less per region and 
spike sizes more often. See attached graphs (the hits is so you can see the 
overall profile of load, mixed, pure-read for 1.2.7 and then for 2.0.0)

> [TESTING] Performance
> -
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
>  Issue Type: Umbrella
>  Components: Performance
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, 
> HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 
> performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs 
> None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, 
> ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, 
> ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, 
> ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, 
> ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, 
> YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, 
> YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, 
> flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, 
> hbase-site.xml, hits.png, lock.127.workloadc.20180402T200918Z.svg, 
> lock.2.memsize2.c.20180403T160257Z.svg, perregion.png, run_ycsb.sh, 
> total.png, tree.txt, workloadx, workloadx
>
>
> How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor 
> that it is much slower, that the problem is the asyncwal writing. Does 
> in-memory compaction slow us down or speed us up? What happens when you 
> enable offheaping?
> Keep notes here in this umbrella issue. Need to be able to say something 
> about perf when 2.0.0 ships.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20188) [TESTING] Performance

2018-04-14 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-20188:
--
Attachment: total.png
perregion.png
hits.png

> [TESTING] Performance
> -
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
>  Issue Type: Umbrella
>  Components: Performance
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, 
> HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 
> performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs 
> None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, 
> ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, 
> ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, 
> ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, 
> ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, 
> YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, 
> YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, 
> flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, 
> hbase-site.xml, hits.png, lock.127.workloadc.20180402T200918Z.svg, 
> lock.2.memsize2.c.20180403T160257Z.svg, perregion.png, run_ycsb.sh, 
> total.png, tree.txt, workloadx, workloadx
>
>
> How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor 
> that it is much slower, that the problem is the asyncwal writing. Does 
> in-memory compaction slow us down or speed us up? What happens when you 
> enable offheaping?
> Keep notes here in this umbrella issue. Need to be able to say something 
> about perf when 2.0.0 ships.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20188) [TESTING] Performance

2018-04-14 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438530#comment-16438530
 ] 

stack commented on HBASE-20188:
---

In my YCSB runs, comparing 1.2.7 to 2.0.0 loads, I see that we carry more in 
hbase memstores but when I look by region, we seem to carry less per region and 
spike sizes more often. See attached graphs (the hits is so you can see the 
overall profile of load, mixed, pure-read for 1.2.7 and then for 2.0.0)

> [TESTING] Performance
> -
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
>  Issue Type: Umbrella
>  Components: Performance
>Reporter: stack
>Assignee: stack
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, 
> HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 
> performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs 
> None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, 
> ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, 
> ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, 
> ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, 
> ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, 
> YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, 
> YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, 
> flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, 
> hbase-site.xml, lock.127.workloadc.20180402T200918Z.svg, 
> lock.2.memsize2.c.20180403T160257Z.svg, run_ycsb.sh, tree.txt, workloadx, 
> workloadx
>
>
> How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor 
> that it is much slower, that the problem is the asyncwal writing. Does 
> in-memory compaction slow us down or speed us up? What happens when you 
> enable offheaping?
> Keep notes here in this umbrella issue. Need to be able to say something 
> about perf when 2.0.0 ships.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20233) [metrics] Ill-formatted numRegions metric in "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438522#comment-16438522
 ] 

Hudson commented on HBASE-20233:


Results for branch branch-2
[build #614 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/614/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/614//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/614//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/614//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> [metrics] Ill-formatted numRegions metric in 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean
> ---
>
> Key: HBASE-20233
> URL: https://issues.apache.org/jira/browse/HBASE-20233
> Project: HBase
>  Issue Type: Bug
>  Components: metrics, Operability
>Reporter: stack
>Assignee: Xu Cang
>Priority: Trivial
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-20233-v1.patch, HBASE-20233.patch
>
>
> Noticed this poking at metrics. The MBean 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" carries per region 
> metrics. They are all formatted like so:
> {code}
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_98th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99.9th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_num_ops:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_min: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_max: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_mean: 
> 0,
> {code}
> In the middle of them all is a metric named...
> {code}
> numRegions: 15,
> {code}
> It has a different format and it is out of scope when compared to the other 
> metrics in this mbean; it belongs better elsewhere, perhaps in the Server 
> bean.
> I noticed it because it breaks the parse done by tcollector scraping our 
> metrics from /jmx
> It was added long ago in HBASE-14166



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438494#comment-16438494
 ] 

Hudson commented on HBASE-20335:


Results for branch branch-1.4
[build #289 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/289/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/289//General_Nightly_Build_Report/]


(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/289//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.4/289//JDK8_Nightly_Build_Report_(Hadoop2)/]




(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20335.0.patch, HBASE-20335.1.patch
>
>
> something is up with nightly jobs. they no longer have the machine 
> information from HBASE-19228.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20406) HBase Thrift HTTP - Shouldn't handle TRACE/OPTIONS methods

2018-04-14 Thread Kevin Risden (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438466#comment-16438466
 ] 

Kevin Risden commented on HBASE-20406:
--

If I were to guess it would be OPTIONS. TRACE is the one that came up on a 
security scan at work. I just used the existing method since it did the trick.

> HBase Thrift HTTP - Shouldn't handle TRACE/OPTIONS methods
> --
>
> Key: HBASE-20406
> URL: https://issues.apache.org/jira/browse/HBASE-20406
> Project: HBase
>  Issue Type: Improvement
>  Components: security, Thrift
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: HBASE-20406.master.001.patch
>
>
> HBASE-10473 introduced a utility HttpServerUtil.constrainHttpMethods to 
> prevent Jetty from answering on TRACE and OPTIONS methods. This should be 
> added to Thrift in HTTP mode as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20411) Ameliorate MutableSegment synchronize

2018-04-14 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438460#comment-16438460
 ] 

stack commented on HBASE-20411:
---

The patch has a problem.. I got into a state where couldn't flush.

> Ameliorate MutableSegment synchronize
> -
>
> Key: HBASE-20411
> URL: https://issues.apache.org/jira/browse/HBASE-20411
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Priority: Major
> Attachments: 2.load.patched.17704.lock.svg, 
> 2.load.patched.2.17704.lock.svg, 41901.lock.svg, 
> HBASE-20411.branch-2.0.001.patch
>
>
> This item is migrated from HBASE-20236 so it gets dedicated issue.
> Let me upload evidence that has this synchronize as a stake in our write-time 
> perf. I'll migrate the patch I posted with updates that come of comments 
> posted by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20411) Ameliorate MutableSegment synchronize

2018-04-14 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438453#comment-16438453
 ] 

stack commented on HBASE-20411:
---

MutableSegment does not show in the locking sampling when the patch is in 
place. See attached 2.load.patched.17704.lock.svg and 
2.load.patched.2.17704.lock.svg Only makes for minor uptick in write throughput 
though.

> Ameliorate MutableSegment synchronize
> -
>
> Key: HBASE-20411
> URL: https://issues.apache.org/jira/browse/HBASE-20411
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Priority: Major
> Attachments: 2.load.patched.17704.lock.svg, 
> 2.load.patched.2.17704.lock.svg, 41901.lock.svg, 
> HBASE-20411.branch-2.0.001.patch
>
>
> This item is migrated from HBASE-20236 so it gets dedicated issue.
> Let me upload evidence that has this synchronize as a stake in our write-time 
> perf. I'll migrate the patch I posted with updates that come of comments 
> posted by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20411) Ameliorate MutableSegment synchronize

2018-04-14 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-20411:
--
Attachment: 2.load.patched.2.17704.lock.svg

> Ameliorate MutableSegment synchronize
> -
>
> Key: HBASE-20411
> URL: https://issues.apache.org/jira/browse/HBASE-20411
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Priority: Major
> Attachments: 2.load.patched.17704.lock.svg, 
> 2.load.patched.2.17704.lock.svg, 41901.lock.svg, 
> HBASE-20411.branch-2.0.001.patch
>
>
> This item is migrated from HBASE-20236 so it gets dedicated issue.
> Let me upload evidence that has this synchronize as a stake in our write-time 
> perf. I'll migrate the patch I posted with updates that come of comments 
> posted by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20411) Ameliorate MutableSegment synchronize

2018-04-14 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-20411:
--
Attachment: 2.load.patched.17704.lock.svg

> Ameliorate MutableSegment synchronize
> -
>
> Key: HBASE-20411
> URL: https://issues.apache.org/jira/browse/HBASE-20411
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Priority: Major
> Attachments: 2.load.patched.17704.lock.svg, 41901.lock.svg, 
> HBASE-20411.branch-2.0.001.patch
>
>
> This item is migrated from HBASE-20236 so it gets dedicated issue.
> Let me upload evidence that has this synchronize as a stake in our write-time 
> perf. I'll migrate the patch I posted with updates that come of comments 
> posted by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20411) Ameliorate MutableSegment synchronize

2018-04-14 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-20411:
--
Status: Patch Available  (was: Open)

.001 
{code}
Change the synchronize across three volatiles incrementing our memory
sizings. Instead:

 * Make MemStoreSize immutable. Create a new instance on every 
increment.
 * Undo MemStoreSizing being an instance of MemStoreSize; instead it 
has-a.
 * Make two MemStoreSizing implementations; one thread-safe, the other 
not.
 * Use an AtomicReference#checkAndPut (lockless) where concurrent 
updates
 * Otherwise, use unsynchronized accounting.

TODO: Conservative using thread-safe accounting when unclear. Fix.
TODO: Use this technique accounting at the global level too.

A 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/LocalMemStoreSizing.java
 Non-thread-safe memory size accounting.

M 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSize.java
 Make MemStoreSize immutable, just a container for three longs.

M 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStoreSizing.java
 Make this an Interface. Implementations are a thread-safe instance and
 a non-thread-safe version.

A 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ThreadSafeMemStoreSizing.java
 Thread-safe version.

{code}

> Ameliorate MutableSegment synchronize
> -
>
> Key: HBASE-20411
> URL: https://issues.apache.org/jira/browse/HBASE-20411
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Priority: Major
> Attachments: 41901.lock.svg, HBASE-20411.branch-2.0.001.patch
>
>
> This item is migrated from HBASE-20236 so it gets dedicated issue.
> Let me upload evidence that has this synchronize as a stake in our write-time 
> perf. I'll migrate the patch I posted with updates that come of comments 
> posted by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20411) Ameliorate MutableSegment synchronize

2018-04-14 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-20411:
--
Attachment: HBASE-20411.branch-2.0.001.patch

> Ameliorate MutableSegment synchronize
> -
>
> Key: HBASE-20411
> URL: https://issues.apache.org/jira/browse/HBASE-20411
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Priority: Major
> Attachments: 41901.lock.svg, HBASE-20411.branch-2.0.001.patch
>
>
> This item is migrated from HBASE-20236 so it gets dedicated issue.
> Let me upload evidence that has this synchronize as a stake in our write-time 
> perf. I'll migrate the patch I posted with updates that come of comments 
> posted by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-19547) HBase fails building on AArch64 due to asciidoctor-maven-plugin.

2018-04-14 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-19547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438433#comment-16438433
 ] 

Mike Drob commented on HBASE-19547:
---

could we scope the dependency to just the plugin? I'm worried about 
accidentally including jruby somewhere where we don't want to be redistributing 
it.

> HBase fails building on AArch64 due to asciidoctor-maven-plugin.
> 
>
> Key: HBASE-19547
> URL: https://issues.apache.org/jira/browse/HBASE-19547
> Project: HBase
>  Issue Type: Bug
>  Components: build, hbase, jruby
>Affects Versions: 3.0.0
>Reporter: Yuqi Gu
>Assignee: Yuqi Gu
>Priority: Major
> Attachments: HBASE-19547.patch
>
>
> HBase fails building on AArch64 due to asciidoctor-maven-plugin.
> {code:java}
> mvn clean site package install -DskipTests 
> [ERROR] Failed to execute 
> goal org.asciidoctor:asciidoctor-maven-plugin:1.5.5:
> process-asciidoc (output-pdf) on project hbase: 
> Execution output-pdf of goal 
> org.asciidoctor:asciidoctor-maven-plugin:1.5.5:
> process-asciidoc failed: (NotImplementedError)
>  fstat unimplemented unsupported or native support failed to load ->
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20411) Ameliorate MutableSegment synchronize

2018-04-14 Thread stack (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438432#comment-16438432
 ] 

stack commented on HBASE-20411:
---

Thanks [~huaxiang] ...  Let me put up what I have here (AtomicReference + 
create new instance of the data structure on every change -- gets rid of the 
synchronize). It looks too like a bunch of the memory accounting doesn't even 
have to be done in a thread safe manner so can do a form of what we did in 
TimeRangeTracker. Once up, lets come back around and look at your suggestion of 
letting the sizings run independent of each other. I think a hack-up patch 
first to see if stuff works if the sizings run independent would be first tack 
(If we could get away with it, your suggestion would be best.).

> Ameliorate MutableSegment synchronize
> -
>
> Key: HBASE-20411
> URL: https://issues.apache.org/jira/browse/HBASE-20411
> Project: HBase
>  Issue Type: Bug
>Reporter: stack
>Priority: Major
> Attachments: 41901.lock.svg
>
>
> This item is migrated from HBASE-20236 so it gets dedicated issue.
> Let me upload evidence that has this synchronize as a stake in our write-time 
> perf. I'll migrate the patch I posted with updates that come of comments 
> posted by [~mdrob] on the HBASE-20236 issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20417) Do not read wal entries when peer is disabled

2018-04-14 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438415#comment-16438415
 ] 

Hadoop QA commented on HBASE-20417:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  6m 
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
24s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
34s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
48s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
17m 11s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
35s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}110m  
7s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
22s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}164m  1s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20417 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12919062/HBASE-20417-v1.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux b2f9a1128c3c 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9 
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / edf5049502 |
| maven | version: Apache Maven 3.5.3 
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12450/testReport/ |
| Max. process+thread count | 4146 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12450/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Do not read wal entries when peer 

[jira] [Commented] (HBASE-20406) HBase Thrift HTTP - Shouldn't handle TRACE/OPTIONS methods

2018-04-14 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438409#comment-16438409
 ] 

Mike Drob commented on HBASE-20406:
---

There was an issue where we discussed allowing the enable of one of these on 
REST because certain rest clients use it to find the available resources? I 
can't find it anymore, [~tedyu] you were on it I think... do you have any idea 
what I'm talking about?

> HBase Thrift HTTP - Shouldn't handle TRACE/OPTIONS methods
> --
>
> Key: HBASE-20406
> URL: https://issues.apache.org/jira/browse/HBASE-20406
> Project: HBase
>  Issue Type: Improvement
>  Components: security, Thrift
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Major
> Attachments: HBASE-20406.master.001.patch
>
>
> HBASE-10473 introduced a utility HttpServerUtil.constrainHttpMethods to 
> prevent Jetty from answering on TRACE and OPTIONS methods. This should be 
> added to Thrift in HTTP mode as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-7129) Need documentation for REST atomic operations (HBASE-4720)

2018-04-14 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-7129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438404#comment-16438404
 ] 

Mike Drob commented on HBASE-7129:
--

manually triggered QA and inspected built guide.

compared to the description for Put directly above your addition in the guide 
some values are not written in {{monospaced}} font.

I'm confused by the examples you provide - I don't see where the 
{{check-value}} is given. Can we make that more explicit?

> Need documentation for REST atomic operations (HBASE-4720)
> --
>
> Key: HBASE-7129
> URL: https://issues.apache.org/jira/browse/HBASE-7129
> Project: HBase
>  Issue Type: Improvement
>  Components: documentation, REST
>Reporter: Joe Pallas
>Assignee: Dequan Chen
>Priority: Minor
>  Labels: beginner
> Attachments: HBASE-7129.0001.patch, HBASE-7129.0002.patch, 
> HBASE-7129.patch
>
>
> HBASE-4720 added checkAndPut/checkAndDelete capability to the REST interface, 
> but the REST documentation (in the package summary) needs to be updated so 
> people know that this feature exists and how to use it.
> http://wiki.apache.org/hadoop/Hbase/Stargate
> http://hbase.apache.org/book/rest.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20294) Also cleanup last pushed sequence id in ReplicationBarrierCleaner

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438400#comment-16438400
 ] 

Hudson commented on HBASE-20294:


Results for branch branch-2
[build #613 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/613/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/613//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/601//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/613//JDK8_Nightly_Build_Report_(Hadoop3)/]




> Also cleanup last pushed sequence id in ReplicationBarrierCleaner
> -
>
> Key: HBASE-20294
> URL: https://issues.apache.org/jira/browse/HBASE-20294
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.1.0
>
> Attachments: HBASE-20294.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20145) HMaster start fails with IllegalStateException when HADOOP_HOME is set

2018-04-14 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438402#comment-16438402
 ] 

Mike Drob commented on HBASE-20145:
---

posted comments on reviewboard

> HMaster start fails with IllegalStateException when HADOOP_HOME is set
> --
>
> Key: HBASE-20145
> URL: https://issues.apache.org/jira/browse/HBASE-20145
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0-beta-1
> Environment: HBase-2.0-beta1.
> Hadoop trunk version.
> java version "1.8.0_144"
>Reporter: Rohith Sharma K S
>Assignee: Wei-Chiu Chuang
>Priority: Major
> Attachments: HBASE-20145.master.001.patch
>
>
> It is observed that HMaster start is failed when HADOOP_HOME is set as env 
> while starting HMaster. HADOOP_HOME is pointing to Hadoop trunk version.
> {noformat}
> 2018-03-07 16:59:52,654 ERROR [master//10.200.4.200:16000] master.HMaster: 
> Failed to become active master
> java.lang.IllegalStateException: The procedure WAL relies on the ability to 
> hsync for proper operation during component failures, but the underlying 
> filesystem does not support doing so. Please check the config value of 
> 'hbase.procedure.store.wal.use.hsync' to set the desired level of robustness 
> and ensure the config value of 'hbase.wal.dir' points to a FileSystem mount 
> that can provide it.
>     at 
> org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.rollWriter(WALProcedureStore.java:1036)
>     at 
> org.apache.hadoop.hbase.procedure2.store.wal.WALProcedureStore.recoverLease(WALProcedureStore.java:374)
>     at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.start(ProcedureExecutor.java:532)
>     at 
> org.apache.hadoop.hbase.master.HMaster.startProcedureExecutor(HMaster.java:1232)
>     at 
> org.apache.hadoop.hbase.master.HMaster.startServiceThreads(HMaster.java:1145)
>     at 
> org.apache.hadoop.hbase.master.HMaster.finishActiveMasterInitialization(HMaster.java:837)
>     at 
> org.apache.hadoop.hbase.master.HMaster.startActiveMasterManager(HMaster.java:2026)
>     at org.apache.hadoop.hbase.master.HMaster.run(HMaster.java:547)
>     at java.lang.Thread.run(Thread.java:748)
> {noformat}
> The same configs is working in HBase-1.2.6 build properly. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20364) nightly job gives old results or no results for stages that timeout on SCM

2018-04-14 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438398#comment-16438398
 ] 

Mike Drob commented on HBASE-20364:
---

makes sense. ship it

> nightly job gives old results or no results for stages that timeout on SCM
> --
>
> Key: HBASE-20364
> URL: https://issues.apache.org/jira/browse/HBASE-20364
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 3.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20364.0.patch
>
>
> seen in the branch-2.0 nightly report for HBASE-18828:
>  
> {quote}
> Results for branch branch-2.0
>  [build #143 on 
> builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/143/]:
>  (x) *\{color:red}-1 overall\{color}*
> 
> details (if available):
> (/) \{color:green}+1 general checks\{color}
> -- For more information [see general 
> report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/140//General_Nightly_Build_Report/]
>  
> (/) \{color:green}+1 jdk8 hadoop2 checks\{color}
> -- For more information [see jdk8 (hadoop2) 
> report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/143//JDK8_Nightly_Build_Report_(Hadoop2)/]
> (/) \{color:green}+1 jdk8 hadoop3 checks\{color}
> -- For more information [see jdk8 (hadoop3) 
> report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/143//JDK8_Nightly_Build_Report_(Hadoop3)/]
>  
> {quote}
>  
> -1 for the overall build was correct. build #143 failed both the general 
> check and the source tarball check.
>  
> but in the posted comment, we get a false "passing" that links to the general 
> result from build #140. and we get no result for the source tarball at all.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20415) branches-2 don't need maven-scala-plugin

2018-04-14 Thread Mike Drob (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438397#comment-16438397
 ] 

Mike Drob commented on HBASE-20415:
---

+1 

> branches-2 don't need maven-scala-plugin
> 
>
> Key: HBASE-20415
> URL: https://issues.apache.org/jira/browse/HBASE-20415
> Project: HBase
>  Issue Type: Task
>  Components: build
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20415-branch-2.v0.patch
>
>
> the spark support revert missed a couple of plugins in the top level pom for 
> making sure we get scaladocs.
> verified there is no scala in the source tree, so these plugins aren't needed.
> {code}
> hbase $ find . -name '*.scala'
> hbase $ 
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-13643) Follow Google to get more 9's

2018-04-14 Thread Mike Drob (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-13643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Drob updated HBASE-13643:
--
Fix Version/s: 3.0.0

> Follow Google to get more 9's
> -
>
> Key: HBASE-13643
> URL: https://issues.apache.org/jira/browse/HBASE-13643
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Priority: Major
> Fix For: 3.0.0
>
>
> Ideas taken shamelessly from Google's HBasecon talk 
> (http://hbasecon.com/agenda/):
> On failover all regions are unavailable for reads (and sometime writes) until 
> after all write ahead logs have been recovered. To combat that the last 
> flushed seqid is kept around.
> Google took this one step farther and set some regions (Tablets in BigTable) 
> as read only. Setting a region as read only means there's no memstore. No 
> need to flush before move, split, or merge.
> In addition to the wins that Google got, HBase would also be able to shed 
> some memory pressure. Right now every region gets a memstore and with that 
> memstore comes a mslab. Read only regions would not need these added object. 
> This should allow a regionserver to host lots of cold regions without too 
> much memory pressure.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20233) [metrics] Ill-formatted numRegions metric in "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean

2018-04-14 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-20233:
--
Component/s: Operability

> [metrics] Ill-formatted numRegions metric in 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean
> ---
>
> Key: HBASE-20233
> URL: https://issues.apache.org/jira/browse/HBASE-20233
> Project: HBase
>  Issue Type: Bug
>  Components: metrics, Operability
>Reporter: stack
>Assignee: Xu Cang
>Priority: Trivial
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-20233-v1.patch, HBASE-20233.patch
>
>
> Noticed this poking at metrics. The MBean 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" carries per region 
> metrics. They are all formatted like so:
> {code}
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_98th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99.9th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_num_ops:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_min: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_max: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_mean: 
> 0,
> {code}
> In the middle of them all is a metric named...
> {code}
> numRegions: 15,
> {code}
> It has a different format and it is out of scope when compared to the other 
> metrics in this mbean; it belongs better elsewhere, perhaps in the Server 
> bean.
> I noticed it because it breaks the parse done by tcollector scraping our 
> metrics from /jmx
> It was added long ago in HBASE-14166



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20233) [metrics] Ill-formatted numRegions metric in "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean

2018-04-14 Thread stack (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack updated HBASE-20233:
--
   Resolution: Fixed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

Pushed to branch-2.0+. Thanks for the nice fix [~xucang]

> [metrics] Ill-formatted numRegions metric in 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" mbean
> ---
>
> Key: HBASE-20233
> URL: https://issues.apache.org/jira/browse/HBASE-20233
> Project: HBase
>  Issue Type: Bug
>  Components: metrics, Operability
>Reporter: stack
>Assignee: Xu Cang
>Priority: Trivial
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-20233-v1.patch, HBASE-20233.patch
>
>
> Noticed this poking at metrics. The MBean 
> "Hadoop:service=HBase,name=RegionServer,sub=Regions" carries per region 
> metrics. They are all formatted like so:
> {code}
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_98th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_incrementTime_99.9th_percentile:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_num_ops:
>  0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_min: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_max: 0,
> Namespace_default_table_IntegrationTestBigLinkedList_metric_appendTime_mean: 
> 0,
> {code}
> In the middle of them all is a metric named...
> {code}
> numRegions: 15,
> {code}
> It has a different format and it is out of scope when compared to the other 
> metrics in this mbean; it belongs better elsewhere, perhaps in the Server 
> bean.
> I noticed it because it breaks the parse done by tcollector scraping our 
> metrics from /jmx
> It was added long ago in HBASE-14166



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20377) Deal with table in enabling and disabling state when modifying serial replication peer

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438356#comment-16438356
 ] 

Hudson commented on HBASE-20377:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Deal with table in enabling and disabling state when modifying serial 
> replication peer
> --
>
> Key: HBASE-20377
> URL: https://issues.apache.org/jira/browse/HBASE-20377
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.1.0
>
> Attachments: HBASE-20377-v1.patch, HBASE-20377.patch
>
>
> There could be race between reopening regions and enabling table, and also 
> between disabling table and write last pushed sequence id for disabled table. 
> Maybe we need to wait for the table state to become enabled or disabled.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20112) Include test results from nightly hadoop3 tests in jenkins test results

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438357#comment-16438357
 ] 

Hudson commented on HBASE-20112:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Include test results from nightly hadoop3 tests in jenkins test results
> ---
>
> Key: HBASE-20112
> URL: https://issues.apache.org/jira/browse/HBASE-20112
> Project: HBase
>  Issue Type: Task
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20112.0.patch
>
>
> right now our nightly tests that run atop hadoop 3 are reported on pass/fail 
> but aren't recorded via the jenkins reporting mechanism.
> we should add them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20379) shadedjars yetus plugin should add a footer link

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438362#comment-16438362
 ] 

Hudson commented on HBASE-20379:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> shadedjars yetus plugin should add a footer link
> 
>
> Key: HBASE-20379
> URL: https://issues.apache.org/jira/browse/HBASE-20379
> Project: HBase
>  Issue Type: Improvement
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20379.0.patch
>
>
> investigating the failure on HBASE-20219, it would be nice if we posted a 
> footer link to what failed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20391) close out stale or finished PRs on github

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438358#comment-16438358
 ] 

Hudson commented on HBASE-20391:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> close out stale or finished PRs on github
> -
>
> Key: HBASE-20391
> URL: https://issues.apache.org/jira/browse/HBASE-20391
> Project: HBase
>  Issue Type: Task
>  Components: community, documentation
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20391.0.patch
>
>
> Time to do another round of closing PRs via empty commit.
> * [#51|https://github.com/apache/hbase/pull/51] - > 1 month since notification
> * [#52|https://github.com/apache/hbase/pull/52] - > 1 month since notification
> * [#61|https://github.com/apache/hbase/pull/61] - HBASE-18928 has already 
> closed
> * [#62|https://github.com/apache/hbase/pull/62] - HBASE-18929 has already 
> closed
> * [#64|https://github.com/apache/hbase/pull/64] -HBASE-18901 has already 
> closed
> * [#67|https://github.com/apache/hbase/pull/67] - HBASE-19386 has already 
> closed
> * [#68|https://github.com/apache/hbase/pull/68] - HBASE-19387 has already 
> closed



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20410) upgrade protoc compiler to 3.5.1-1

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438359#comment-16438359
 ] 

Hudson commented on HBASE-20410:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> upgrade protoc compiler to 3.5.1-1
> --
>
> Key: HBASE-20410
> URL: https://issues.apache.org/jira/browse/HBASE-20410
> Project: HBase
>  Issue Type: Bug
>  Components: build, dependencies, Protobufs
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 2.0.0
>
> Attachments: HBASE-20410.patch
>
>
> See HBASE-20356
> After doing the cleanup there, I was informed that there's a 3.5.1-1 version 
> of the compiler binaries that work on rhel6, so let's just go to that. Wish I 
> knew about it beforehand.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20344) Fix asciidoc warnings

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438355#comment-16438355
 ] 

Hudson commented on HBASE-20344:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Fix asciidoc warnings
> -
>
> Key: HBASE-20344
> URL: https://issues.apache.org/jira/browse/HBASE-20344
> Project: HBase
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 2.0.0
>Reporter: Peter Somogyi
>Assignee: Peter Somogyi
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20344.master.001.patch, 
> HBASE-20344.master.001.patch, HBASE-20344.master.002.patch
>
>
> IntelliJ shows some warnings for asciidoc files.
> 1. Markdown Style Heading:
> \### Required properties
>  
> 2. Asciidoc Old Style Heading:
> Creating a New Table with Compression On a ColumnFamily
>  
>  \
> hbase> create 'test2', \{ NAME => 'cf2', COMPRESSION => 'SNAPPY' }
>  \
>  
> 3. Warning during build
> asciidoctor: WARNING: _chapters/troubleshooting.adoc: line 105: invalid style 
> for listing block: NOTE



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20291) Fix for The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no dependency information available with hadoop.profile=3.0

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438360#comment-16438360
 ] 

Hudson commented on HBASE-20291:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Fix for The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no 
> dependency information available with hadoop.profile=3.0
> ---
>
> Key: HBASE-20291
> URL: https://issues.apache.org/jira/browse/HBASE-20291
> Project: HBase
>  Issue Type: Bug
>Reporter: Artem Ervits
>Assignee: Artem Ervits
>Priority: Minor
> Fix For: 3.0.0
>
> Attachments: HBASE-20291.v01.patch, HBASE-20291.v02.patch
>
>
> receiving message
> {code:java}
> The POM for net.minidev:json-smart:jar:2.3-SNAPSHOT is missing, no dependency 
> information available{code}
> when running with
> {code:java}
> mvn clean install -DHBasePatchProcess -Dhadoop-three.version=3.0.0 
> -Dhadoop.profile=3.0 -DskipTests{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20389) Move website building flags into a profile

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438363#comment-16438363
 ] 

Hudson commented on HBASE-20389:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Move website building flags into a profile
> --
>
> Key: HBASE-20389
> URL: https://issues.apache.org/jira/browse/HBASE-20389
> Project: HBase
>  Issue Type: Improvement
>  Components: build, website
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 3.0.0, 2.1.0, 2.0.1
>
> Attachments: HBASE-20389.0.patch, HBASE-20389.1.patch
>
>
> we have some "magic" in our website building right now. The script that's 
> used bout our automated website build + publish mechanism manually sets a 
> bunch of stuff on the maven command line.
> It'd be better to reflect those settings in a maven profile, so that folks 
> are less likely to be surprised e.g. when trying to debug a failure in the 
> {{site}} goal happens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438361#comment-16438361
 ] 

Hudson commented on HBASE-20335:


Results for branch master
[build #299 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/299/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//General_Nightly_Build_Report/]




(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/299//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20335.0.patch, HBASE-20335.1.patch
>
>
> something is up with nightly jobs. they no longer have the machine 
> information from HBASE-19228.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20417) Do not read wal entries when peer is disabled

2018-04-14 Thread Duo Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-20417:
--
Attachment: HBASE-20417-v1.patch

> Do not read wal entries when peer is disabled
> -
>
> Key: HBASE-20417
> URL: https://issues.apache.org/jira/browse/HBASE-20417
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.1.0
>
> Attachments: HBASE-20417-v1.patch, HBASE-20417.patch
>
>
> Now, the disabled check is in ReplicationSourceShipper. If peer is disabled, 
> then we will not take entry batch from ReplicationSourceWALReader. But 
> ReplicationSourceWALReader will keep reading wal entries until the buffer is 
> full.
> For serial replication, the canPush check is in ReplicationSourceWALReader, 
> so even when we disabled the peer during the modification for a serial peer, 
> we could still run into the SerialReplicationChecker. Theoretically there 
> will be no problem, since in the procedure we will only update last pushed 
> sequence ids to a greater value. If canPush is true then a greater value does 
> not make any difference, if canPush is false then we are still safe since the 
> ReplicationSourceWALReader will be blocked.
> But this still makes me a little nervous, and also, it does not make sense to 
> still read wal entries when the peer is disabled. So let's change the 
> behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-18812) Recategorize some of classes used as tools

2018-04-14 Thread Chia-Ping Tsai (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-18812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438325#comment-16438325
 ] 

Chia-Ping Tsai commented on HBASE-18812:


[~andrewcheng] Thanks for the sharing.
 # Given that the 2.0 is in RC phase, limiting the scope from Public to LP is 
inappropriate.
 # Also, the test-purposed class should be not declared LP. If someone assume 
they belong to Public tool for user, we should move them out of test folder 
first. 
 # ditto for example code

a little busy recently, so please feel free to take over this Jira 
[~andrewcheng]. I'm happy to review the patch.

 

 

> Recategorize some of classes used as tools
> --
>
> Key: HBASE-18812
> URL: https://issues.apache.org/jira/browse/HBASE-18812
> Project: HBase
>  Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
>
> The classes used from cmd line should be made as LimitedPrivate.TOOLS. The 
> candidates are shown below.
> # BackupDriver
> # RestoreDriver
> # CreateSnapshot
> # SnapshotInfo
> # ExportSnapshot
> # Canary
> # VersionInfo
> # RegionMover
> # CellCounter
> # CopyTable
> # DumpReplicationQueues
> # Export
> # HashTable
> # Import
> # ImportTsv
> # LoadIncrementalHFiles
> # ReplicationSyncUp
> # SyncTable
> # VerifyReplication
> # WALPlayer
> # ZkAclReset



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438309#comment-16438309
 ] 

Hudson commented on HBASE-20335:


Results for branch branch-2.0
[build #175 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175//JDK8_Nightly_Build_Report_(Hadoop3)/]




> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20335.0.patch, HBASE-20335.1.patch
>
>
> something is up with nightly jobs. they no longer have the machine 
> information from HBASE-19228.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20389) Move website building flags into a profile

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438310#comment-16438310
 ] 

Hudson commented on HBASE-20389:


Results for branch branch-2.0
[build #175 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/175//JDK8_Nightly_Build_Report_(Hadoop3)/]




> Move website building flags into a profile
> --
>
> Key: HBASE-20389
> URL: https://issues.apache.org/jira/browse/HBASE-20389
> Project: HBase
>  Issue Type: Improvement
>  Components: build, website
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 3.0.0, 2.1.0, 2.0.1
>
> Attachments: HBASE-20389.0.patch, HBASE-20389.1.patch
>
>
> we have some "magic" in our website building right now. The script that's 
> used bout our automated website build + publish mechanism manually sets a 
> bunch of stuff on the maven command line.
> It'd be better to reflect those settings in a maven profile, so that folks 
> are less likely to be surprised e.g. when trying to debug a failure in the 
> {{site}} goal happens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20417) Do not read wal entries when peer is disabled

2018-04-14 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438305#comment-16438305
 ] 

Hadoop QA commented on HBASE-20417:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
25s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m 
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
26s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
29s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
13m 15s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m 
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
27s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}107m 56s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
22s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}149m 51s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.replication.regionserver.TestWALEntryStream 
|
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:d8b550f |
| JIRA Issue | HBASE-20417 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12919054/HBASE-20417.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 213254df0893 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / edf5049502 |
| maven | version: Apache Maven 3.5.3 
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12449/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 

[jira] [Commented] (HBASE-20389) Move website building flags into a profile

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438302#comment-16438302
 ] 

Hudson commented on HBASE-20389:


Results for branch branch-2
[build #612 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/612/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/611//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/612//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/612//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> Move website building flags into a profile
> --
>
> Key: HBASE-20389
> URL: https://issues.apache.org/jira/browse/HBASE-20389
> Project: HBase
>  Issue Type: Improvement
>  Components: build, website
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Fix For: 3.0.0, 2.1.0, 2.0.1
>
> Attachments: HBASE-20389.0.patch, HBASE-20389.1.patch
>
>
> we have some "magic" in our website building right now. The script that's 
> used bout our automated website build + publish mechanism manually sets a 
> bunch of stuff on the maven command line.
> It'd be better to reflect those settings in a maven profile, so that folks 
> are less likely to be surprised e.g. when trying to debug a failure in the 
> {{site}} goal happens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438301#comment-16438301
 ] 

Hudson commented on HBASE-20335:


Results for branch branch-2
[build #612 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/612/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(/) {color:green}+1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/611//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/612//JDK8_Nightly_Build_Report_(Hadoop2)/]


(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/612//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20335.0.patch, HBASE-20335.1.patch
>
>
> something is up with nightly jobs. they no longer have the machine 
> information from HBASE-19228.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20112) Include test results from nightly hadoop3 tests in jenkins test results

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438298#comment-16438298
 ] 

Hudson commented on HBASE-20112:


Results for branch branch-1
[build #283 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283//General_Nightly_Build_Report/]


(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283//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/283//JDK8_Nightly_Build_Report_(Hadoop2)/]




(x) {color:red}-1 source release artifact{color}
-- See build output for details.


> Include test results from nightly hadoop3 tests in jenkins test results
> ---
>
> Key: HBASE-20112
> URL: https://issues.apache.org/jira/browse/HBASE-20112
> Project: HBase
>  Issue Type: Task
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20112.0.patch
>
>
> right now our nightly tests that run atop hadoop 3 are reported on pass/fail 
> but aren't recorded via the jenkins reporting mechanism.
> we should add them.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20379) shadedjars yetus plugin should add a footer link

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438299#comment-16438299
 ] 

Hudson commented on HBASE-20379:


Results for branch branch-1
[build #283 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283//General_Nightly_Build_Report/]


(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283//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/283//JDK8_Nightly_Build_Report_(Hadoop2)/]




(x) {color:red}-1 source release artifact{color}
-- See build output for details.


> shadedjars yetus plugin should add a footer link
> 
>
> Key: HBASE-20379
> URL: https://issues.apache.org/jira/browse/HBASE-20379
> Project: HBase
>  Issue Type: Improvement
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20379.0.patch
>
>
> investigating the failure on HBASE-20219, it would be nice if we posted a 
> footer link to what failed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438300#comment-16438300
 ] 

Hudson commented on HBASE-20335:


Results for branch branch-1
[build #283 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283//General_Nightly_Build_Report/]


(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/283//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/283//JDK8_Nightly_Build_Report_(Hadoop2)/]




(x) {color:red}-1 source release artifact{color}
-- See build output for details.


> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20335.0.patch, HBASE-20335.1.patch
>
>
> something is up with nightly jobs. they no longer have the machine 
> information from HBASE-19228.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20415) branches-2 don't need maven-scala-plugin

2018-04-14 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438281#comment-16438281
 ] 

Hadoop QA commented on HBASE-20415:
---

| (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} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red}  0m  
0s{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} branch-2 Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  7m 
 1s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 21m  
5s{color} | {color:green} branch-2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
24s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
58s{color} | {color:green} branch-2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 20m 
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 20m 
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green}  0m  
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
 4s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
11m 20s{color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.5 2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
16s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}157m 
44s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
31s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}236m  8s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:dba4808 |
| JIRA Issue | HBASE-20415 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12919046/HBASE-20415-branch-2.v0.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  shadedjars  hadoopcheck  
xml  compile  |
| uname | Linux 5d244f84ecf9 3.13.0-139-generic #188-Ubuntu SMP Tue Jan 9 
14:43:09 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | branch-2 / 1d133c005c |
| maven | version: Apache Maven 3.5.3 
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12448/testReport/ |
| Max. process+thread count | 4524 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12448/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> branches-2 don't need maven-scala-plugin
> 
>
> Key: HBASE-20415
> URL: https://issues.apache.org/jira/browse/HBASE-20415
> Project: HBase
>  Issue Type: Task
>  Components: build
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20415-branch-2.v0.patch
>
>
> the spark support revert missed a couple 

[jira] [Commented] (HBASE-20404) Ugly cleanerchore complaint that dir is not empty

2018-04-14 Thread Reid Chan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438274#comment-16438274
 ] 

Reid Chan commented on HBASE-20404:
---

I prefer before checking,  but i'm afraid it still chatty..
 

> Ugly cleanerchore complaint that dir is not empty
> -
>
> Key: HBASE-20404
> URL: https://issues.apache.org/jira/browse/HBASE-20404
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20404.0.patch, HBASE-20404.1.patch
>
>
>  I see these big dirty exceptions in my master log during a long-run Lets 
> clean them up (Are they exceptions I as an operator can actually do something 
> about? Are they 'problems'? Should they be LOG.warn?)
> {code}
> 2018-04-12 16:02:09,911 WARN  [ForkJoinPool-1-worker-15] 
> cleaner.CleanerChore: Could not delete dir under 
> hdfs://ve0524.halxg.cloudera.com:8020/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta;
>  {}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.fs.PathIsNotEmptyDirectoryException):
>  
> `/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta
>  is non empty': Directory is not empty
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSDirDeleteOp.delete(FSDirDeleteOp.java:115)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.delete(FSNamesystem.java:2848)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.delete(NameNodeRpcServer.java:1048)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.delete(ClientNamenodeProtocolServerSideTranslatorPB.java:641)
>   at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:447)
>   at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:989)
>   at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:847)
>   at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:790)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1836)
>   at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2486)
>   at org.apache.hadoop.ipc.Client.getRpcResponse(Client.java:1489)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1435)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1345)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:227)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:116)
>   at com.sun.proxy.$Proxy26.delete(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.delete(ClientNamenodeProtocolTranslatorPB.java:568)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:409)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:163)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:155)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:346)
>   at com.sun.proxy.$Proxy27.delete(Unknown Source)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
> ...
> {code}
> Looks like log format is off too...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20417) Do not read wal entries when peer is disabled

2018-04-14 Thread Duo Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-20417:
--
 Assignee: Duo Zhang
Fix Version/s: 2.1.0
   3.0.0
   Status: Patch Available  (was: Open)

> Do not read wal entries when peer is disabled
> -
>
> Key: HBASE-20417
> URL: https://issues.apache.org/jira/browse/HBASE-20417
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.1.0
>
> Attachments: HBASE-20417.patch
>
>
> Now, the disabled check is in ReplicationSourceShipper. If peer is disabled, 
> then we will not take entry batch from ReplicationSourceWALReader. But 
> ReplicationSourceWALReader will keep reading wal entries until the buffer is 
> full.
> For serial replication, the canPush check is in ReplicationSourceWALReader, 
> so even when we disabled the peer during the modification for a serial peer, 
> we could still run into the SerialReplicationChecker. Theoretically there 
> will be no problem, since in the procedure we will only update last pushed 
> sequence ids to a greater value. If canPush is true then a greater value does 
> not make any difference, if canPush is false then we are still safe since the 
> ReplicationSourceWALReader will be blocked.
> But this still makes me a little nervous, and also, it does not make sense to 
> still read wal entries when the peer is disabled. So let's change the 
> behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20417) Do not read wal entries when peer is disabled

2018-04-14 Thread Duo Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-20417:
--
Attachment: HBASE-20417.patch

> Do not read wal entries when peer is disabled
> -
>
> Key: HBASE-20417
> URL: https://issues.apache.org/jira/browse/HBASE-20417
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Priority: Major
> Attachments: HBASE-20417.patch
>
>
> Now, the disabled check is in ReplicationSourceShipper. If peer is disabled, 
> then we will not take entry batch from ReplicationSourceWALReader. But 
> ReplicationSourceWALReader will keep reading wal entries until the buffer is 
> full.
> For serial replication, the canPush check is in ReplicationSourceWALReader, 
> so even when we disabled the peer during the modification for a serial peer, 
> we could still run into the SerialReplicationChecker. Theoretically there 
> will be no problem, since in the procedure we will only update last pushed 
> sequence ids to a greater value. If canPush is true then a greater value does 
> not make any difference, if canPush is false then we are still safe since the 
> ReplicationSourceWALReader will be blocked.
> But this still makes me a little nervous, and also, it does not make sense to 
> still read wal entries when the peer is disabled. So let's change the 
> behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (HBASE-20417) Do not read wal entries when peer is disabled

2018-04-14 Thread Duo Zhang (JIRA)
Duo Zhang created HBASE-20417:
-

 Summary: Do not read wal entries when peer is disabled
 Key: HBASE-20417
 URL: https://issues.apache.org/jira/browse/HBASE-20417
 Project: HBase
  Issue Type: Sub-task
  Components: Replication
Reporter: Duo Zhang


Now, the disabled check is in ReplicationSourceShipper. If peer is disabled, 
then we will not take entry batch from ReplicationSourceWALReader. But 
ReplicationSourceWALReader will keep reading wal entries until the buffer is 
full.

For serial replication, the canPush check is in ReplicationSourceWALReader, so 
even when we disabled the peer during the modification for a serial peer, we 
could still run into the SerialReplicationChecker. Theoretically there will be 
no problem, since in the procedure we will only update last pushed sequence ids 
to a greater value. If canPush is true then a greater value does not make any 
difference, if canPush is false then we are still safe since the 
ReplicationSourceWALReader will be blocked.

But this still makes me a little nervous, and also, it does not make sense to 
still read wal entries when the peer is disabled. So let's change the behavior.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (HBASE-20239) Scheduled chore task to clean up the last pushed sequence id for the expired regions.

2018-04-14 Thread Duo Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang resolved HBASE-20239.
---
Resolution: Duplicate

We will delete last pushed sequence ids in ReplicationBarrierCleaner, so close 
this issue as duplicated.

> Scheduled chore task to clean up the last pushed sequence id for the expired 
> regions. 
> --
>
> Key: HBASE-20239
> URL: https://issues.apache.org/jira/browse/HBASE-20239
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20416) [DOC] Fix hbck option intros

2018-04-14 Thread Wei-Chiu Chuang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wei-Chiu Chuang updated HBASE-20416:

Component/s: documentation

> [DOC] Fix hbck option intros
> 
>
> Key: HBASE-20416
> URL: https://issues.apache.org/jira/browse/HBASE-20416
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Wei-Chiu Chuang
>Priority: Major
>
> {quote}
> In this case, you can use the -fixSplitParents 
> This option should not normally be used, and it is not in -fixAll.
> {quote}
> There is no such option "-fixAll". From the context, it seems to refer to 
> -repair
> In addition, -repair option also covers -fixReferenceFiles, -fixHFileLinks, 
> which are not introduced in the doc.
> {code:title=HBaseFsck#exec}
> else if (cmd.equals("-repair")) {
> // this attempts to merge overlapping hdfs regions, needs testing
> // under load
> setFixHdfsHoles(true);
> setFixHdfsOrphans(true);
> setFixMeta(true);
> setFixAssignments(true);
> setFixHdfsOverlaps(true);
> setFixVersionFile(true);
> setSidelineBigOverlaps(true);
> setFixSplitParents(false);
> setCheckHdfs(true);
> setFixReferenceFiles(true);
> setFixHFileLinks(true);
> {code}
> {quote}
> -repair includes all the region consistency options and only the hole 
> repairing table integrity options.
> {quote}
> ... seems untrue to me.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20294) Also cleanup last pushed sequence id in ReplicationBarrierCleaner

2018-04-14 Thread Duo Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Duo Zhang updated HBASE-20294:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.1.0
   Status: Resolved  (was: Patch Available)

Pushed to master and branch-2.

Thanks [~openinx] for reviewing.

> Also cleanup last pushed sequence id in ReplicationBarrierCleaner
> -
>
> Key: HBASE-20294
> URL: https://issues.apache.org/jira/browse/HBASE-20294
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.1.0
>
> Attachments: HBASE-20294.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (HBASE-20416) [DOC] Fix hbck option intros

2018-04-14 Thread Wei-Chiu Chuang (JIRA)
Wei-Chiu Chuang created HBASE-20416:
---

 Summary: [DOC] Fix hbck option intros
 Key: HBASE-20416
 URL: https://issues.apache.org/jira/browse/HBASE-20416
 Project: HBase
  Issue Type: Bug
Reporter: Wei-Chiu Chuang


{quote}
In this case, you can use the -fixSplitParents 
This option should not normally be used, and it is not in -fixAll.
{quote}
There is no such option "-fixAll". From the context, it seems to refer to 
-repair

In addition, -repair option also covers -fixReferenceFiles, -fixHFileLinks, 
which are not introduced in the doc.

{code:title=HBaseFsck#exec}
else if (cmd.equals("-repair")) {
// this attempts to merge overlapping hdfs regions, needs testing
// under load
setFixHdfsHoles(true);
setFixHdfsOrphans(true);
setFixMeta(true);
setFixAssignments(true);
setFixHdfsOverlaps(true);
setFixVersionFile(true);
setSidelineBigOverlaps(true);
setFixSplitParents(false);
setCheckHdfs(true);
setFixReferenceFiles(true);
setFixHFileLinks(true);
{code}

{quote}
-repair includes all the region consistency options and only the hole repairing 
table integrity options.
{quote}
... seems untrue to me.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20404) Ugly cleanerchore complaint that dir is not empty

2018-04-14 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438247#comment-16438247
 ] 

Sean Busbey commented on HBASE-20404:
-

as  I mentioned above, I don't think we can remove logging in the general case 
of an IOException.

I'm trying out the debug message for sort order, but it's way too chatty.

What about expressly checking for the directory being empty? either before 
trying to delete or after catching the IOException?

> Ugly cleanerchore complaint that dir is not empty
> -
>
> Key: HBASE-20404
> URL: https://issues.apache.org/jira/browse/HBASE-20404
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20404.0.patch, HBASE-20404.1.patch
>
>
>  I see these big dirty exceptions in my master log during a long-run Lets 
> clean them up (Are they exceptions I as an operator can actually do something 
> about? Are they 'problems'? Should they be LOG.warn?)
> {code}
> 2018-04-12 16:02:09,911 WARN  [ForkJoinPool-1-worker-15] 
> cleaner.CleanerChore: Could not delete dir under 
> hdfs://ve0524.halxg.cloudera.com:8020/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta;
>  {}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.fs.PathIsNotEmptyDirectoryException):
>  
> `/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta
>  is non empty': Directory is not empty
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSDirDeleteOp.delete(FSDirDeleteOp.java:115)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.delete(FSNamesystem.java:2848)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.delete(NameNodeRpcServer.java:1048)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.delete(ClientNamenodeProtocolServerSideTranslatorPB.java:641)
>   at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:447)
>   at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:989)
>   at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:847)
>   at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:790)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1836)
>   at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2486)
>   at org.apache.hadoop.ipc.Client.getRpcResponse(Client.java:1489)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1435)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1345)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:227)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:116)
>   at com.sun.proxy.$Proxy26.delete(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.delete(ClientNamenodeProtocolTranslatorPB.java:568)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:409)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:163)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:155)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:346)
>   at com.sun.proxy.$Proxy27.delete(Unknown Source)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
> ...
> {code}
> Looks like log format is off too...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-20404) Ugly cleanerchore complaint that dir is not empty

2018-04-14 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-20404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-20404:

Status: In Progress  (was: Patch Available)

> Ugly cleanerchore complaint that dir is not empty
> -
>
> Key: HBASE-20404
> URL: https://issues.apache.org/jira/browse/HBASE-20404
> Project: HBase
>  Issue Type: Bug
>  Components: master
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Sean Busbey
>Priority: Major
> Attachments: HBASE-20404.0.patch, HBASE-20404.1.patch
>
>
>  I see these big dirty exceptions in my master log during a long-run Lets 
> clean them up (Are they exceptions I as an operator can actually do something 
> about? Are they 'problems'? Should they be LOG.warn?)
> {code}
> 2018-04-12 16:02:09,911 WARN  [ForkJoinPool-1-worker-15] 
> cleaner.CleanerChore: Could not delete dir under 
> hdfs://ve0524.halxg.cloudera.com:8020/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta;
>  {}
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.fs.PathIsNotEmptyDirectoryException):
>  
> `/hbase/archive/data/default/IntegrationTestBigLinkedList/1e24549061df3adc4858fbcaf1929553/meta
>  is non empty': Directory is not empty
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSDirDeleteOp.delete(FSDirDeleteOp.java:115)
>   at 
> org.apache.hadoop.hdfs.server.namenode.FSNamesystem.delete(FSNamesystem.java:2848)
>   at 
> org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.delete(NameNodeRpcServer.java:1048)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.delete(ClientNamenodeProtocolServerSideTranslatorPB.java:641)
>   at 
> org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:447)
>   at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:989)
>   at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:847)
>   at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:790)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at javax.security.auth.Subject.doAs(Subject.java:422)
>   at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1836)
>   at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2486)
>   at org.apache.hadoop.ipc.Client.getRpcResponse(Client.java:1489)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1435)
>   at org.apache.hadoop.ipc.Client.call(Client.java:1345)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:227)
>   at 
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:116)
>   at com.sun.proxy.$Proxy26.delete(Unknown Source)
>   at 
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.delete(ClientNamenodeProtocolTranslatorPB.java:568)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:409)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeMethod(RetryInvocationHandler.java:163)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invoke(RetryInvocationHandler.java:155)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler$Call.invokeOnce(RetryInvocationHandler.java:95)
>   at 
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:346)
>   at com.sun.proxy.$Proxy27.delete(Unknown Source)
>   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
> ...
> {code}
> Looks like log format is off too...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-20335) nightly jobs no longer contain machine information

2018-04-14 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-20335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438246#comment-16438246
 ] 

Hudson commented on HBASE-20335:


Results for branch HBASE-20335
[build #4 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20335/4/]: 
(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-20335/4//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-20335/4//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-20335/4//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


> nightly jobs no longer contain machine information
> --
>
> Key: HBASE-20335
> URL: https://issues.apache.org/jira/browse/HBASE-20335
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.3.3, 1.4.4, 2.0.1
>
> Attachments: HBASE-20335.0.patch, HBASE-20335.1.patch
>
>
> something is up with nightly jobs. they no longer have the machine 
> information from HBASE-19228.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)