[jira] [Commented] (HBASE-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[Hudson (JIRA)]

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

Hudson commented on HBASE-20272:


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


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


> TestAsyncTable#testCheckAndMutateWithTimeRange fails due to 
> TableExistsException
> 
>
> Key: HBASE-20272
> URL: https://issues.apache.org/jira/browse/HBASE-20272
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20272.v1.txt, 20272.v2.txt
>
>
> The following test failure is reproducible:
> {code}
> org.apache.hadoop.hbase.TableExistsException: testCheckAndMutateWithTimeRange
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:233)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:87)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:51)
>  at 
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:184)
>  at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:845)
>  at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1453)
> {code}
> The cause was that TestAsyncTable is parameterized while the 
> testCheckAndMutateWithTimeRange uses the same table name without dropping the 
> table after the first invocation finishes.
> This leads to second invocation failing with TableExistsException.



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

[jira] [Commented] (HBASE-19504) Add TimeRange support into checkAndMutate

[Hudson (JIRA)]

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

Hudson commented on HBASE-19504:


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


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


> Add TimeRange support into checkAndMutate
> -
>
> Key: HBASE-19504
> URL: https://issues.apache.org/jira/browse/HBASE-19504
> Project: HBase
>  Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19504.v0.patch
>
>




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

[jira] [Commented] (HBASE-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[Hudson (JIRA)]

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

Hudson commented on HBASE-20272:


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


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


> TestAsyncTable#testCheckAndMutateWithTimeRange fails due to 
> TableExistsException
> 
>
> Key: HBASE-20272
> URL: https://issues.apache.org/jira/browse/HBASE-20272
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20272.v1.txt, 20272.v2.txt
>
>
> The following test failure is reproducible:
> {code}
> org.apache.hadoop.hbase.TableExistsException: testCheckAndMutateWithTimeRange
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:233)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:87)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:51)
>  at 
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:184)
>  at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:845)
>  at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1453)
> {code}
> The cause was that TestAsyncTable is parameterized while the 
> testCheckAndMutateWithTimeRange uses the same table name without dropping the 
> table after the first invocation finishes.
> This leads to second invocation failing with TableExistsException.



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

[jira] [Commented] (HBASE-19504) Add TimeRange support into checkAndMutate

[Hudson (JIRA)]

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

Hudson commented on HBASE-19504:


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


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


> Add TimeRange support into checkAndMutate
> -
>
> Key: HBASE-19504
> URL: https://issues.apache.org/jira/browse/HBASE-19504
> Project: HBase
>  Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19504.v0.patch
>
>




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

[jira] [Commented] (HBASE-20260) Purge old content from the book for branch-2/master

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-20260:
-

+1

> Purge old content from the book for branch-2/master
> ---
>
> Key: HBASE-20260
> URL: https://issues.apache.org/jira/browse/HBASE-20260
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0.0-beta-2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20260.patch, HBASE-20260.v2.patch, 
> HBASE-20260.v3.patch
>
>
> there's lots of old content that we should clean up to make room for new 
> content. old warnings that don't matter any more, properties that don't 
> exist, etc...



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

[jira] [Updated] (HBASE-20264) Update Java prerequisite section with LTS rec and status of current GA JDKs

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-20264:

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

thanks for the review Zach!

(still docs only patch, which is why still no tests and why the unit failures 
are unrelated)

> Update Java prerequisite section with LTS rec and status of current GA JDKs
> ---
>
> Key: HBASE-20264
> URL: https://issues.apache.org/jira/browse/HBASE-20264
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Fix For: 3.0.0
>
> Attachments: HBASE-20264.0.patch, HBASE-20264.1.patch
>
>
> Per the thread [\[DISCUSS\] strategy on Java 
> versions|https://lists.apache.org/thread.html/b7417aa8359e1beaa7caf47e8fa524296c499974e7467a541c6df415@%3Cdev.hbase.apache.org%3E]
> * Add Java 9 and Java 10 to the support matrix as NT
> * Add a NOTE to Java prereqs about "use a LTS version"
> For now, leave out talk about planning for timelines on LTS additions or 
> dropping older JDK support. Once we get over the initial hurdle of prepping 
> for Java 11 we'll hopefully have enough info to know how realistic the things 
> talked about in the thread are and we can include a writeup.



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

[jira] [Commented] (HBASE-20264) Update Java prerequisite section with LTS rec and status of current GA JDKs

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20264:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
37s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color: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} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
49s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
41s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}156m  8s{color} 
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
24s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}173m  2s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20264 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916075/HBASE-20264.1.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  |
| uname | Linux c948f1cc3b8b 3.13.0-137-generic #186-Ubuntu SMP Mon Dec 4 
19:09:19 UTC 2017 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 / ce702df41b |
| maven | version: Apache Maven 3.5.3 
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12128/artifact/patchprocess/patch-unit-root.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12128/testReport/ |
| Max. process+thread count | 4588 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12128/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Update Java prerequisite section with LTS rec and status of current GA JDKs
> ---
>
> Key: HBASE-20264
> URL: https://issues.apache.org/jira/browse/HBASE-20264
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20264.0.patch, HBASE-20264.1.patch
>
>
> Per the thread [\[DISCUSS\] strategy on Java 
> versions|https://lists.apache.org/thread.html/b7417aa8359e1beaa7caf47e8fa524296c499974e7467a541c6df415@%3Cdev.hbase.apache.org%3E]
> * Add Java 9 and Java 10 to the support matrix as NT
> * Add a NOTE to Java prereqs about "use a LTS version"
> For now, leave out talk about planning for timelines on LTS additions or 
> dropping older JDK support. Once we get over the initial hurdle of prepping 
> for Java 11 we'll hopefully have enough info to know how realistic the things 
> talked about in the thread are and we can include a writeup.



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

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

[Eshcar Hillel (JIRA)]

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

Eshcar Hillel commented on HBASE-20188:
---

Something to consider:
When I ran the experiments to determine the optimal default values for 
in-memory compaction (HBASE-16417), I ran them with CAM setting and no mslab.
My findings for the optimal setting (for SSD) were a threshold of 2% for the 
active segment (hbase.memstore.inmemoryflush.threshold.factor=0.02) and 
pipeline length of 4 (hbase.hregion.compacting.pipeline.segments.limit=4), and 
3 for hdd.
*However*, the current settings are different:
1) using mslab (which means CCM setting and not CAM)
2) the active segment threshold was changed and is now 
hbase.memstore.inmemoryflush.threshold.factor=0.1
But the pipeline length is still set to 4.
This doesn't make much sense. If we flush "only" after aggregating 10% of the 
data in the active segment we can use a pipeline of length 1, this would be  
equivalent to a longer pipeline (of length 4) with smaller segments (consisting 
of 2% of the data).
I hope what I am saying here makes sense.

Bottom line, given that the threshold was changed to 10%, I would recommend 
changing the pipeline length to 1. This should mainly have a positive affect on 
read latency. And regardless, presuming mslab is default (which is not what we 
recommend) may require an additional round of parameter tuning.
 

> [TESTING] Performance
> -
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
>  Issue Type: Umbrella
>  Components: Performance
>Reporter: stack
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 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, tree.txt
>
>
> 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-20260) Purge old content from the book for branch-2/master

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20260:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
18s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color: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} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
36s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m 
38s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}175m 
35s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
30s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}190m 44s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20260 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916073/HBASE-20260.v3.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  |
| uname | Linux d97c6f772219 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 / 4c203a9be0 |
| 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/12127/testReport/ |
| Max. process+thread count | 4980 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12127/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Purge old content from the book for branch-2/master
> ---
>
> Key: HBASE-20260
> URL: https://issues.apache.org/jira/browse/HBASE-20260
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0.0-beta-2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20260.patch, HBASE-20260.v2.patch, 
> HBASE-20260.v3.patch
>
>
> there's lots of old content that we should clean up to make room for new 
> content. old warnings that don't matter any more, properties that don't 
> exist, etc...



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

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

[Eshcar Hillel (JIRA)]

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

Eshcar Hillel commented on HBASE-20188:
---

Stack the table with throughput and latency numbers you posted is very helpful 
(looking at the figures, it is much harder to say which settings are at each 
run).
Can you give the same table with the none numbers?
BTW -- do you have the 50th and 99th latency percentiles (mainly for reads)? 
They are much more informative than the average latency which is somewhere 
between them. 

> [TESTING] Performance
> -
>
> Key: HBASE-20188
> URL: https://issues.apache.org/jira/browse/HBASE-20188
> Project: HBase
>  Issue Type: Umbrella
>  Components: Performance
>Reporter: stack
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: 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, tree.txt
>
>
> 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-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[Ted Yu (JIRA)]

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

Ted Yu commented on HBASE-20272:


bq. No reference to the issue that caused the problem

When I logged the JIRA, I was looking at why the TableExistsException happened 
in the test.
I didn't look at git log closely to see which commit resulted in the test 
failure.

Later I realized this was a regression. By the time I was about to link to 
related issue, you already added the link (I needed to drive my kids to various 
activities on Saturday). 

Thanks for adding the link to the related issue, BTW.

bq. Why not just do an addendum on the original?

See above - I didn't pinpoint the related issue in the first place. I also 
didn't want to cause confusion in case wrong issue was identified.

I will refer to the history more closely and use addendum on the original issue 
in the future for test breakage.

> TestAsyncTable#testCheckAndMutateWithTimeRange fails due to 
> TableExistsException
> 
>
> Key: HBASE-20272
> URL: https://issues.apache.org/jira/browse/HBASE-20272
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20272.v1.txt, 20272.v2.txt
>
>
> The following test failure is reproducible:
> {code}
> org.apache.hadoop.hbase.TableExistsException: testCheckAndMutateWithTimeRange
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:233)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:87)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:51)
>  at 
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:184)
>  at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:845)
>  at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1453)
> {code}
> The cause was that TestAsyncTable is parameterized while the 
> testCheckAndMutateWithTimeRange uses the same table name without dropping the 
> table after the first invocation finishes.
> This leads to second invocation failing with TableExistsException.



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

[jira] [Commented] (HBASE-19504) Add TimeRange support into checkAndMutate

[stack (JIRA)]

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

stack commented on HBASE-19504:
---

Arghh...Reverted the above ADDENDUM and instead pushed to branch-2 and 
branch-2.0 the patch on HBASE-20272 -- which was in master only -- instead (For 
some reason, an issue was opened to push a super minor addendum to a test...)

> Add TimeRange support into checkAndMutate
> -
>
> Key: HBASE-19504
> URL: https://issues.apache.org/jira/browse/HBASE-19504
> Project: HBase
>  Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19504.v0.patch
>
>




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

[jira] [Resolved] (HBASE-19504) Add TimeRange support into checkAndMutate

[stack (JIRA)]

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

stack resolved HBASE-19504.
---
Resolution: Fixed

> Add TimeRange support into checkAndMutate
> -
>
> Key: HBASE-19504
> URL: https://issues.apache.org/jira/browse/HBASE-19504
> Project: HBase
>  Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19504.v0.patch
>
>




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

[jira] [Commented] (HBASE-20264) Update Java prerequisite section with LTS rec and status of current GA JDKs

[Zach York (JIRA)]

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

Zach York commented on HBASE-20264:
---

+1, thanks Sean

> Update Java prerequisite section with LTS rec and status of current GA JDKs
> ---
>
> Key: HBASE-20264
> URL: https://issues.apache.org/jira/browse/HBASE-20264
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20264.0.patch, HBASE-20264.1.patch
>
>
> Per the thread [\[DISCUSS\] strategy on Java 
> versions|https://lists.apache.org/thread.html/b7417aa8359e1beaa7caf47e8fa524296c499974e7467a541c6df415@%3Cdev.hbase.apache.org%3E]
> * Add Java 9 and Java 10 to the support matrix as NT
> * Add a NOTE to Java prereqs about "use a LTS version"
> For now, leave out talk about planning for timelines on LTS additions or 
> dropping older JDK support. Once we get over the initial hurdle of prepping 
> for Java 11 we'll hopefully have enough info to know how realistic the things 
> talked about in the thread are and we can include a writeup.



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

[jira] [Commented] (HBASE-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[stack (JIRA)]

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

stack commented on HBASE-20272:
---

There are a few problems with this issue.

 # No reference to the issue that caused the problem (HBASE-19504)
 # Why not just do an addendum on the original?


> TestAsyncTable#testCheckAndMutateWithTimeRange fails due to 
> TableExistsException
> 
>
> Key: HBASE-20272
> URL: https://issues.apache.org/jira/browse/HBASE-20272
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20272.v1.txt, 20272.v2.txt
>
>
> The following test failure is reproducible:
> {code}
> org.apache.hadoop.hbase.TableExistsException: testCheckAndMutateWithTimeRange
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:233)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:87)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:51)
>  at 
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:184)
>  at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:845)
>  at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1453)
> {code}
> The cause was that TestAsyncTable is parameterized while the 
> testCheckAndMutateWithTimeRange uses the same table name without dropping the 
> table after the first invocation finishes.
> This leads to second invocation failing with TableExistsException.



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

[jira] [Commented] (HBASE-20257) hbase-spark should not depend on com.google.code.findbugs.jsr305

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-20257:
-

if the dependency can be removed, you should also switch the module back to 
using the enforcer rule that ensures we don't have that dependency pop up. You 
should be able to do that by removing the enforcer section that says it's 
making the rule warn instead of fail.

> hbase-spark should not depend on com.google.code.findbugs.jsr305
> 
>
> Key: HBASE-20257
> URL: https://issues.apache.org/jira/browse/HBASE-20257
> Project: HBase
>  Issue Type: Task
>  Components: build
>Affects Versions: 3.0.0
>Reporter: Ted Yu
>Assignee: Artem Ervits
>Priority: Minor
>  Labels: beginner
> Attachments: HBASE-20257.v01.patch
>
>
> The following can be observed in the build output of master branch:
> {code}
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed 
> with message:
> We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
> Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> {code}
> Here is related snippet from hbase-spark/pom.xml:
> {code}
> 
>   com.google.code.findbugs
>   jsr305
> {code}
> Dependency on jsr305 should be dropped.



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

[jira] [Updated] (HBASE-20257) hbase-spark should not depend on com.google.code.findbugs.jsr305

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-20257:

Status: In Progress  (was: Patch Available)

moving out of PA pending update.

> hbase-spark should not depend on com.google.code.findbugs.jsr305
> 
>
> Key: HBASE-20257
> URL: https://issues.apache.org/jira/browse/HBASE-20257
> Project: HBase
>  Issue Type: Task
>  Components: build
>Affects Versions: 3.0.0
>Reporter: Ted Yu
>Assignee: Artem Ervits
>Priority: Minor
>  Labels: beginner
> Attachments: HBASE-20257.v01.patch
>
>
> The following can be observed in the build output of master branch:
> {code}
> [WARNING] Rule 0: org.apache.maven.plugins.enforcer.BannedDependencies failed 
> with message:
> We don't allow the JSR305 jar from the Findbugs project, see HBASE-16321.
> Found Banned Dependency: com.google.code.findbugs:jsr305:jar:1.3.9
> Use 'mvn dependency:tree' to locate the source of the banned dependencies.
> {code}
> Here is related snippet from hbase-spark/pom.xml:
> {code}
> 
>   com.google.code.findbugs
>   jsr305
> {code}
> Dependency on jsr305 should be dropped.



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

[jira] [Commented] (HBASE-20264) Update Java prerequisite section with LTS rec and status of current GA JDKs

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-20264:
-

-v1
  - removed proposed note from jdk7 entries since the issue it refers to 
impacts jdk7 and jdk8.

> Update Java prerequisite section with LTS rec and status of current GA JDKs
> ---
>
> Key: HBASE-20264
> URL: https://issues.apache.org/jira/browse/HBASE-20264
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20264.0.patch, HBASE-20264.1.patch
>
>
> Per the thread [\[DISCUSS\] strategy on Java 
> versions|https://lists.apache.org/thread.html/b7417aa8359e1beaa7caf47e8fa524296c499974e7467a541c6df415@%3Cdev.hbase.apache.org%3E]
> * Add Java 9 and Java 10 to the support matrix as NT
> * Add a NOTE to Java prereqs about "use a LTS version"
> For now, leave out talk about planning for timelines on LTS additions or 
> dropping older JDK support. Once we get over the initial hurdle of prepping 
> for Java 11 we'll hopefully have enough info to know how realistic the things 
> talked about in the thread are and we can include a writeup.



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

[jira] [Updated] (HBASE-20264) Update Java prerequisite section with LTS rec and status of current GA JDKs

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-20264:

Attachment: HBASE-20264.1.patch

> Update Java prerequisite section with LTS rec and status of current GA JDKs
> ---
>
> Key: HBASE-20264
> URL: https://issues.apache.org/jira/browse/HBASE-20264
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20264.0.patch, HBASE-20264.1.patch
>
>
> Per the thread [\[DISCUSS\] strategy on Java 
> versions|https://lists.apache.org/thread.html/b7417aa8359e1beaa7caf47e8fa524296c499974e7467a541c6df415@%3Cdev.hbase.apache.org%3E]
> * Add Java 9 and Java 10 to the support matrix as NT
> * Add a NOTE to Java prereqs about "use a LTS version"
> For now, leave out talk about planning for timelines on LTS additions or 
> dropping older JDK support. Once we get over the initial hurdle of prepping 
> for Java 11 we'll hopefully have enough info to know how realistic the things 
> talked about in the thread are and we can include a writeup.



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

[jira] [Commented] (HBASE-19504) Add TimeRange support into checkAndMutate

[stack (JIRA)]

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

stack commented on HBASE-19504:
---

Pushed this addendum to branc-2.0+ to fix failing test...

commit 5da92ce35297821d13757d67994d040173847413
Author: Michael Stack 
Date:   Sat Mar 24 12:29:45 2018 -0700

HBASE-19504 Add TimeRange support into checkAndMutate; ADDENDUM to fix 
failing unit test

diff --git 
a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTable.java 
b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTable.java
index 576c0a728c..e11c8697cc 100644
--- 
a/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTable.java
+++ 
b/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTable.java
@@ -342,7 +342,8 @@ public class TestAsyncTable {

   @Test
   public void testCheckAndMutateWithTimeRange() throws Exception {
-
TEST_UTIL.createTable(TableName.valueOf("testCheckAndMutateWithTimeRange"), 
FAMILY);
+TEST_UTIL.createTable(TableName.valueOf("testCheckAndMutateWithTimeRange" +
+System.currentTimeMillis()), FAMILY);
 AsyncTable table = getTable.get();
 final long ts = System.currentTimeMillis() / 2;
 Put put = new Put(row);

> Add TimeRange support into checkAndMutate
> -
>
> Key: HBASE-19504
> URL: https://issues.apache.org/jira/browse/HBASE-19504
> Project: HBase
>  Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19504.v0.patch
>
>




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

[jira] [Reopened] (HBASE-19504) Add TimeRange support into checkAndMutate

[stack (JIRA)]

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

stack reopened HBASE-19504:
---

Reopen to push addendum.

> Add TimeRange support into checkAndMutate
> -
>
> Key: HBASE-19504
> URL: https://issues.apache.org/jira/browse/HBASE-19504
> Project: HBase
>  Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19504.v0.patch
>
>




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

[jira] [Commented] (HBASE-20260) Purge old content from the book for branch-2/master

[stack (JIRA)]

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

stack commented on HBASE-20260:
---

bq. If you're on anything older than 1.2, my intent is to direct folks to the 
appropriate version docs.

I like it

> Purge old content from the book for branch-2/master
> ---
>
> Key: HBASE-20260
> URL: https://issues.apache.org/jira/browse/HBASE-20260
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0.0-beta-2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20260.patch, HBASE-20260.v2.patch, 
> HBASE-20260.v3.patch
>
>
> there's lots of old content that we should clean up to make room for new 
> content. old warnings that don't matter any more, properties that don't 
> exist, etc...



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

[jira] [Updated] (HBASE-20260) Purge old content from the book for branch-2/master

[Mike Drob (JIRA)]

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

Mike Drob updated HBASE-20260:
--
Attachment: HBASE-20260.v3.patch

> Purge old content from the book for branch-2/master
> ---
>
> Key: HBASE-20260
> URL: https://issues.apache.org/jira/browse/HBASE-20260
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0.0-beta-2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20260.patch, HBASE-20260.v2.patch, 
> HBASE-20260.v3.patch
>
>
> there's lots of old content that we should clean up to make room for new 
> content. old warnings that don't matter any more, properties that don't 
> exist, etc...



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

[jira] [Commented] (HBASE-20260) Purge old content from the book for branch-2/master

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-20260:
---

{quote}
This bit is still needed I think? Probably for a "Upgrading from 1.0 to 1.1+" 
section? Or is your goal to leave out all EOM releases? If so, then the section 
should be "Upgrade to 1.2+" or something like that.
{quote}
If you're on anything older than 1.2, my intent is to direct folks to the 
appropriate version docs.

> Purge old content from the book for branch-2/master
> ---
>
> Key: HBASE-20260
> URL: https://issues.apache.org/jira/browse/HBASE-20260
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0.0-beta-2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20260.patch, HBASE-20260.v2.patch
>
>
> there's lots of old content that we should clean up to make room for new 
> content. old warnings that don't matter any more, properties that don't 
> exist, etc...



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

[jira] [Created] (HBASE-20283) update documentation around default compaction schedule

[Mike Drob (JIRA)]

Mike Drob created HBASE-20283:
-

 Summary: update documentation around default compaction schedule
 Key: HBASE-20283
 URL: https://issues.apache.org/jira/browse/HBASE-20283
 Project: HBase
  Issue Type: Bug
  Components: documentation
Reporter: Mike Drob


Our documentation currently states that compactions default to once a week.

>From [~stack]'s comments:

{quote}
We should file an issue to update the compactions section: "By default, major 
compactions are scheduled to run once in a 7-day period." Should talk about how 
dumb our default is, that operators should run them themselves..., the tooling 
available, etc.
{quote}



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

[jira] [Commented] (HBASE-20260) Purge old content from the book for branch-2/master

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-20260:
---

v3: rebased to master

Filed HBASE-20282 for various tooling updates.

Semantic Versioning is now "Aspirational Semantic Versioning"

I have no idea what network-IO-safe is, I assumed it means something like not 
storming the network by doing it staggered.

Filed HBASE-20283 for improving the compaction guidance.


> Purge old content from the book for branch-2/master
> ---
>
> Key: HBASE-20260
> URL: https://issues.apache.org/jira/browse/HBASE-20260
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.0.0-beta-2
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-20260.patch, HBASE-20260.v2.patch
>
>
> there's lots of old content that we should clean up to make room for new 
> content. old warnings that don't matter any more, properties that don't 
> exist, etc...



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

[jira] [Created] (HBASE-20282) Provide short name invocations for useful tools

[Mike Drob (JIRA)]

Mike Drob created HBASE-20282:
-

 Summary: Provide short name invocations for useful tools
 Key: HBASE-20282
 URL: https://issues.apache.org/jira/browse/HBASE-20282
 Project: HBase
  Issue Type: Bug
  Components: documentation, tooling
Reporter: Mike Drob


We have some tooling that can be made more friendly.

{{bin/hbase ltt}} with no arguments should print usage instead of a stack trace.
{{bin/hbase canary}} usage should refer to itself as {{canary}} not 
{{o.a.h.h.tool.Canary}}
{{bin/hbase org.apache.hadoop.hbase.util.RegionSplitter}} should be shortened 
to {{bin/hbase regionsplitter}}. Usage should be updated to reflect the short 
name.

The fix here MUST also include updates to the book/documentation for the tools.



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

[jira] [Commented] (HBASE-20223) Use hbase-thirdparty 2.1.0

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-20223:
---

That wasn't clear at all to me. :)

Can we make sure that we have ample docs on evangelizing shaded-client and 
shaded-mapreduce? cc: [~busbey]

Meanwhile, +1 on patch.

> Use hbase-thirdparty 2.1.0
> --
>
> Key: HBASE-20223
> URL: https://issues.apache.org/jira/browse/HBASE-20223
> Project: HBase
>  Issue Type: Task
>  Components: dependencies
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20223.001.patch, HBASE-20223.002.branch-2.0.patch
>
>
> Update hbase to account for the changes to hbase-thirdparty:
>  * new (internal) protobuf version
>  * shaded commons-cli
>  * shaded commons-collections4



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

[jira] [Updated] (HBASE-19158) Ref guide needs upgrade update

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-19158:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Ref guide needs upgrade update
> --
>
> Key: HBASE-19158
> URL: https://issues.apache.org/jira/browse/HBASE-19158
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.0.0-beta-1
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-19158.0.patch, HBASE-19158.1.patch, 
> HBASE-19158.2.patch, HBASE-19158.3.patch
>
>
> Our ref guide has lots of references in the upgrade section to obsolete 
> versions and no references to the 2.0.0-* releases. We should correct this 
> for beta-1



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

[jira] [Commented] (HBASE-20223) Use hbase-thirdparty 2.1.0

[Josh Elser (JIRA)]

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

Josh Elser commented on HBASE-20223:


{quote}So on HBASE-20201 you used the normal hbase-mapreduce jar and not the 
shaded one? Trying to understand how we actually end up where we are
{quote}
Correct, I hope this is clear over on HBASE-20201, shout if not. We found this 
via "HBase 1.x" ways of submitting mapreduce jobs (fat jar with dependencies or 
with libjars and {{$(hbase mapredcp)}}).

> Use hbase-thirdparty 2.1.0
> --
>
> Key: HBASE-20223
> URL: https://issues.apache.org/jira/browse/HBASE-20223
> Project: HBase
>  Issue Type: Task
>  Components: dependencies
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20223.001.patch, HBASE-20223.002.branch-2.0.patch
>
>
> Update hbase to account for the changes to hbase-thirdparty:
>  * new (internal) protobuf version
>  * shaded commons-cli
>  * shaded commons-collections4



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

[jira] [Commented] (HBASE-19158) Ref guide needs upgrade update

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-19158:
-

attached v3 for what I pushed.

> Ref guide needs upgrade update
> --
>
> Key: HBASE-19158
> URL: https://issues.apache.org/jira/browse/HBASE-19158
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.0.0-beta-1
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-19158.0.patch, HBASE-19158.1.patch, 
> HBASE-19158.2.patch, HBASE-19158.3.patch
>
>
> Our ref guide has lots of references in the upgrade section to obsolete 
> versions and no references to the 2.0.0-* releases. We should correct this 
> for beta-1



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

[jira] [Updated] (HBASE-19158) Ref guide needs upgrade update

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-19158:

Attachment: HBASE-19158.3.patch

> Ref guide needs upgrade update
> --
>
> Key: HBASE-19158
> URL: https://issues.apache.org/jira/browse/HBASE-19158
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.0.0-beta-1
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-19158.0.patch, HBASE-19158.1.patch, 
> HBASE-19158.2.patch, HBASE-19158.3.patch
>
>
> Our ref guide has lots of references in the upgrade section to obsolete 
> versions and no references to the 2.0.0-* releases. We should correct this 
> for beta-1



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

[jira] [Commented] (HBASE-19158) Ref guide needs upgrade update

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-19158:
-

added one more subtask because the bucket cache stuff was bothering me.

I also just noticed after rebasing that the comments I had in the new doc were 
being displayed (because asciidoc escapes html characters when making html, 
which I should have probably expected). I've switched them to asciidoc comments 
for pushing.

> Ref guide needs upgrade update
> --
>
> Key: HBASE-19158
> URL: https://issues.apache.org/jira/browse/HBASE-19158
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 2.0.0-beta-1
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-19158.0.patch, HBASE-19158.1.patch, 
> HBASE-19158.2.patch
>
>
> Our ref guide has lots of references in the upgrade section to obsolete 
> versions and no references to the 2.0.0-* releases. We should correct this 
> for beta-1



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

[jira] [Commented] (HBASE-20281) [DOC] upgrade section needs an explanation of changes to Bucket Cache

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-20281:
-

@ram_krish and @anoop.hbase, you folks know who could explain this well?

> [DOC] upgrade section needs an explanation of changes to Bucket Cache
> -
>
> Key: HBASE-20281
> URL: https://issues.apache.org/jira/browse/HBASE-20281
> Project: HBase
>  Issue Type: Sub-task
>  Components: BucketCache, documentation
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0
>
>
> the first pass version of the upgrade docs has a brief note about the bucket 
> cache changing:
> {quote}
> * hbase.bucketcache.combinedcache.enabled 
> * hbase.bucketcache.ioengine no longer supports the 'heap' value.  
> {quote}
> But the changes are substantial and warrant a section of their own under the  
> "Changes of Note!" banner.



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

[jira] [Comment Edited] (HBASE-20281) [DOC] upgrade section needs an explanation of changes to Bucket Cache

[Sean Busbey (JIRA)]

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

Sean Busbey edited comment on HBASE-20281 at 3/24/18 3:43 PM:
--

[~ram_krish] and [~anoop.hbase], you folks know who could explain this well?


was (Author: busbey):
@ram_krish and @anoop.hbase, you folks know who could explain this well?

> [DOC] upgrade section needs an explanation of changes to Bucket Cache
> -
>
> Key: HBASE-20281
> URL: https://issues.apache.org/jira/browse/HBASE-20281
> Project: HBase
>  Issue Type: Sub-task
>  Components: BucketCache, documentation
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Priority: Critical
> Fix For: 2.0.0
>
>
> the first pass version of the upgrade docs has a brief note about the bucket 
> cache changing:
> {quote}
> * hbase.bucketcache.combinedcache.enabled 
> * hbase.bucketcache.ioengine no longer supports the 'heap' value.  
> {quote}
> But the changes are substantial and warrant a section of their own under the  
> "Changes of Note!" banner.



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

[jira] [Created] (HBASE-20281) [DOC] upgrade section needs an explanation of changes to Bucket Cache

[Sean Busbey (JIRA)]

Sean Busbey created HBASE-20281:
---

 Summary: [DOC] upgrade section needs an explanation of changes to 
Bucket Cache
 Key: HBASE-20281
 URL: https://issues.apache.org/jira/browse/HBASE-20281
 Project: HBase
  Issue Type: Sub-task
  Components: BucketCache, documentation
Affects Versions: 2.0.0
Reporter: Sean Busbey
 Fix For: 2.0.0


the first pass version of the upgrade docs has a brief note about the bucket 
cache changing:

{quote}
* hbase.bucketcache.combinedcache.enabled 
* hbase.bucketcache.ioengine no longer supports the 'heap' value.  
{quote}

But the changes are substantial and warrant a section of their own under the  
"Changes of Note!" banner.



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

[jira] [Commented] (HBASE-20264) Update Java prerequisite section with LTS rec and status of current GA JDKs

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-20264:
-

It's down in the Hadoop section. It looks like this:

{quote}
Hadoop Pre-2.6.1 and JDK 1.8 Kerberos
When using pre-2.6.1 Hadoop versions and JDK 1.8 in a Kerberos environment, 
HBase server can fail and abort due to Kerberos keytab relogin error. Late 
version of JDK 1.7 (1.7.0_80) has the problem too. Refer to HADOOP-10786 for 
additional details. Consider upgrading to Hadoop 2.6.1+ in this case.
{quote}

Now that I read the note I see that it also impacts JDK8, so probably not worth 
a call out in the Java support section. Let me put up an updated patch.

> Update Java prerequisite section with LTS rec and status of current GA JDKs
> ---
>
> Key: HBASE-20264
> URL: https://issues.apache.org/jira/browse/HBASE-20264
> Project: HBase
>  Issue Type: Task
>  Components: documentation
>Affects Versions: 1.5.0, 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-20264.0.patch
>
>
> Per the thread [\[DISCUSS\] strategy on Java 
> versions|https://lists.apache.org/thread.html/b7417aa8359e1beaa7caf47e8fa524296c499974e7467a541c6df415@%3Cdev.hbase.apache.org%3E]
> * Add Java 9 and Java 10 to the support matrix as NT
> * Add a NOTE to Java prereqs about "use a LTS version"
> For now, leave out talk about planning for timelines on LTS additions or 
> dropping older JDK support. Once we get over the initial hurdle of prepping 
> for Java 11 we'll hopefully have enough info to know how realistic the things 
> talked about in the thread are and we can include a writeup.



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

[jira] [Commented] (HBASE-20130) Document the ports used by RS are changed to 16201/16301 when the RS is bound to localhost

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-20130:
-

Sounds like we have consensus. Should move this from a sub-task to a top level 
issue and change things back, with a release note?

> Document the ports used by RS are changed to 16201/16301 when the RS is bound 
> to localhost
> --
>
> Key: HBASE-20130
> URL: https://issues.apache.org/jira/browse/HBASE-20130
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Umesh Agashe
>Priority: Critical
> Fix For: 2.0.0
>
>




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

[jira] [Commented] (HBASE-20093) Replace ServerLoad by ServerMetrics for ServerManager

[stack (JIRA)]

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

stack commented on HBASE-20093:
---

Thank you [~chia7712]. Let me dig more.  There seems to be a few things that 
are off. Will open new issue. Thanks for checking 

> Replace ServerLoad by ServerMetrics for ServerManager
> -
>
> Key: HBASE-20093
> URL: https://issues.apache.org/jira/browse/HBASE-20093
> Project: HBase
>  Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20093.addendum.patch, HBASE-20093.v0.patch, 
> HBASE-20093.v1.patch
>
>




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

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-20227:
--
Component/s: test

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication, test
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227-v8.patch, HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch, HBASE-20227.master.006.patch, 
> HBASE-20227.master.007.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-20227:
--
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Pushed to master after fixing the checkstyle issue.

Thanks [~tianjingyun] for contributing.

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication, test
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227-v8.patch, HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch, HBASE-20227.master.006.patch, 
> HBASE-20227.master.007.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Commented] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20227:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
38s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
57s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  0m 
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
12s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
16s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
11s{color} | {color:red} hbase-replication: The patch generated 1 new + 0 
unchanged - 0 fixed = 1 total (was 0) {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 
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} 
19m 33s{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}  0m 
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
11s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
21s{color} | {color:green} hbase-replication in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
 9s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 38m  3s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20227 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916061/HBASE-20227-v8.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 907fd9782286 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 / c44e886860 |
| maven | version: Apache Maven 3.5.3 
(3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T19:49:05Z) |
| Default Java | 1.8.0_162 |
| findbugs | v3.1.0-RC3 |
| checkstyle | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12126/artifact/patchprocess/diff-checkstyle-hbase-replication.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12126/testReport/ |
| Max. process+thread count | 152 (vs. ulimit of 1) |
| modules | C: hbase-replication U: hbase-replication |
| Console output | 

[jira] [Updated] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-20271:
--
Issue Type: Sub-task  (was: Bug)
Parent: HBASE-20046

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20271.patch
>
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> 

[jira] [Commented] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-20271:
---

Pushed to master. Leave this issue open for a while to see if it works.

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20271.patch
>
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> 

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-20227:
--
Attachment: HBASE-20227-v8.patch

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227-v8.patch, HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch, HBASE-20227.master.006.patch, 
> HBASE-20227.master.007.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Commented] (HBASE-20223) Use hbase-thirdparty 2.1.0

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-20223:
---

So on HBASE-20201 you used the normal hbase-mapreduce jar and not the shaded 
one? Trying to understand how we actually end up where we are

> Use hbase-thirdparty 2.1.0
> --
>
> Key: HBASE-20223
> URL: https://issues.apache.org/jira/browse/HBASE-20223
> Project: HBase
>  Issue Type: Task
>  Components: dependencies
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: HBASE-20223.001.patch, HBASE-20223.002.branch-2.0.patch
>
>
> Update hbase to account for the changes to hbase-thirdparty:
>  * new (internal) protobuf version
>  * shaded commons-cli
>  * shaded commons-collections4



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

[jira] [Commented] (HBASE-20270) Turn off command help that follows all errors in shell

[Mike Drob (JIRA)]

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

Mike Drob commented on HBASE-20270:
---

Patch looks ok, I think we should also print a line "for usage try 'create 
--help'" or whatever the actual command would be.

Automated testing would have to go into one of the ruby test sources, shouldn't 
be any surprises there to check the command output

> Turn off command help that follows all errors in shell
> --
>
> Key: HBASE-20270
> URL: https://issues.apache.org/jira/browse/HBASE-20270
> Project: HBase
>  Issue Type: Task
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sakthi
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: hbase-20270.master.001.patch
>
>
> Right now if a shell command gives an error, any error, it then echos the 
> command help. It makes it harder to see the actual error text and is annoying.
> example:
> {code}
>   
>   
>
> hbase(main):007:0> create 'test:a_table', 'family', { NUMREGIONS => 20, 
> SPLITALGO => 'HexStringSplit'}
> ERROR: Unknown namespace test!
> Creates a table. Pass a table name, and a set of column family
> specifications (at least one), and, optionally, table configuration.
> Column specification can be a simple string (name), or a dictionary
> (dictionaries are described below in main help output), necessarily
> including NAME attribute.
> Examples:
> Create a table with namespace=ns1 and table qualifier=t1
>   hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}
> Create a table with namespace=default and table qualifier=t1
>   hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}
>   hbase> # The above in shorthand would be the following:
>   hbase> create 't1', 'f1', 'f2', 'f3'
>   hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000, 
> BLOCKCACHE => true}
>   hbase> create 't1', {NAME => 'f1', CONFIGURATION => 
> {'hbase.hstore.blockingStoreFiles' => '10'}}
>   hbase> create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 
> 100, MOB_COMPACT_PARTITION_POLICY => 'weekly'}
> Table configuration options can be put at the end.
> Examples:
>   hbase> create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']
>   hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']
>   hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'
>   hbase> create 't1', {NAME => 'f1', VERSIONS => 5}, METADATA => { 'mykey' => 
> 'myvalue' }
>   hbase> # Optionally pre-split the table into NUMREGIONS, using
>   hbase> # SPLITALGO ("HexStringSplit", "UniformSplit" or classname)
>   hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
>   hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit', 
> REGION_REPLICATION => 2, CONFIGURATION => 
> {'hbase.hregion.scan.loadColumnFamiliesOnDemand' => 'true'}}
>   hbase> create 't1', {NAME => 'f1', DFS_REPLICATION => 1}
> You can also keep around a reference to the created table:
>   hbase> t1 = create 't1', 'f1'
> Which gives you a reference to the table named 't1', on which you can then
> call methods.
> Took 0.0221 seconds   
>   
> 
> hbase(main):008:0> create_namespace 'test'
> Took 0.2554 seconds   
>   
> 
> hbase(main):009:0> create 'test:a_table', 'family', { NUMREGIONS => 20, 
> SPLITALGO => 'HexStringSplit'}
> Created table test:a_table
> Took 1.2264 seconds 
> {code}
> I was trying to make a table in the test namespace before making the 
> namespace. Much faster to recognize and move on when the error text isn't 
> followed by 80x the text.



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

[jira] [Commented] (HBASE-20135) NullPointerException during reading bloom filter when upgraded from hbase-1 to hbase-2

[Hudson (JIRA)]

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

Hudson commented on HBASE-20135:


Results for branch master
[build #271 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/271/]: (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/master/271//General_Nightly_Build_Report/]




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


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


> NullPointerException during reading bloom filter when upgraded from hbase-1 
> to hbase-2
> --
>
> Key: HBASE-20135
> URL: https://issues.apache.org/jira/browse/HBASE-20135
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0-beta-2
>Reporter: Umesh Agashe
>Assignee: Sakthi
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: hbase-20135.master.001.patch, 
> hbase-20135.master.002.patch
>
>
> When upgraded from hbase-1 to hbase-2, found following exception logged 
> multiple times in the log:
> {code:java}
> ERROR [StoreFileOpenerThread-test_cf-1] regionserver.StoreFileReader: Error 
> reading bloom filter meta for GENERAL_BLOOM_META -- proceeding without
> java.io.IOException: Comparator class 
> org.apache.hadoop.hbase.KeyValue$RawBytesComparator is not instantiable
>         at 
> org.apache.hadoop.hbase.io.hfile.FixedFileTrailer.createComparator(FixedFileTrailer.java:628)
>         at 
> org.apache.hadoop.hbase.io.hfile.CompoundBloomFilter.(CompoundBloomFilter.java:79)
>         at 
> org.apache.hadoop.hbase.util.BloomFilterFactory.createFromMeta(BloomFilterFactory.java:104)
>         at 
> org.apache.hadoop.hbase.regionserver.StoreFileReader.loadBloomfilter(StoreFileReader.java:479)
>         at 
> org.apache.hadoop.hbase.regionserver.HStoreFile.open(HStoreFile.java:425)
>         at 
> org.apache.hadoop.hbase.regionserver.HStoreFile.initReader(HStoreFile.java:460)
>         at 
> org.apache.hadoop.hbase.regionserver.HStore.createStoreFileAndReader(HStore.java:671)
>         at 
> org.apache.hadoop.hbase.regionserver.HStore.lambda$openStoreFiles$0(HStore.java:537)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException{code}
>  
> Analysis from [~anoop.hbase]:
> Checking the related code.  There seems no issue..  We are not going
> to even fail reading the bloom.  In 2.0 code base we expect the
> comparator class name to be null.  But in 1.x we write old KV based
> Raw Bytes comparator class name.  So reading that back, we will return
> class name as null and we get NPE it looks like.
> {code:java}
>  else if 
> (comparatorClassName.equals("org.apache.hadoop.hbase.KeyValue$RawBytesComparator")
>         || 
> comparatorClassName.equals("org.apache.hadoop.hbase.util.Bytes$ByteArrayComparator"))
> {
>       // When the comparator to be used is Bytes.BYTES_RAWCOMPARATOR,
> we just return null from here
>       // Bytes.BYTES_RAWCOMPARATOR is not a CellComparator
>       comparatorKlass = null;
>     }
> {code}
> We can better do a null check before trying the comparator class
> instantiation so that we can avoid this scary error logs



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

[jira] [Commented] (HBASE-20245) HTrace commands do not work

[Hudson (JIRA)]

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

Hudson commented on HBASE-20245:


Results for branch master
[build #271 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/271/]: (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/master/271//General_Nightly_Build_Report/]




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


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


> HTrace commands do not work
> ---
>
> Key: HBASE-20245
> URL: https://issues.apache.org/jira/browse/HBASE-20245
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20245.master.001.patch
>
>
> When running shell-2.0 against server-2.0 we get the following error:
> {code}
> hbase(main):034:0> trace 'start'
> ERROR: undefined method `isTracing' for 
> Java::OrgApacheHtraceCore::Tracer:Class
> {code}
> It is possible to manipulate tracing from shell-1.2.



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

[jira] [Commented] (HBASE-20261) Table page (table.jsp) in Master UI does not show replicaIds for hbase meta table

[Hudson (JIRA)]

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

Hudson commented on HBASE-20261:


Results for branch master
[build #271 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/271/]: (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/master/271//General_Nightly_Build_Report/]




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


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


> Table page (table.jsp) in Master UI does not show replicaIds for hbase meta 
> table
> -
>
> Key: HBASE-20261
> URL: https://issues.apache.org/jira/browse/HBASE-20261
> Project: HBase
>  Issue Type: Bug
>  Components: UI
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Fix For: 1.5.0, 2.0.0
>
> Attachments: HBASE-20261.master.001.patch, Screen Shot 2018-03-23 at 
> 12.05.27.png
>
>
> When region replication is enabled for hbase meta table, the table page 
> (table.jsp) in Master UI does not show replicaIds for hbase meta table. It 
> only shows the header:
> !Screen Shot 2018-03-23 at 12.05.27.png! 



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

[jira] [Commented] (HBASE-16848) Usage for show_peer_tableCFs command doesn't include peer

[Hudson (JIRA)]

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

Hudson commented on HBASE-16848:


Results for branch master
[build #271 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/271/]: (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/master/271//General_Nightly_Build_Report/]




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


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


> Usage for show_peer_tableCFs command doesn't include peer
> -
>
> Key: HBASE-16848
> URL: https://issues.apache.org/jira/browse/HBASE-16848
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Peter Somogyi
>Priority: Minor
>  Labels: documentation, replication, shell
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.4.3, 2.0.0
>
> Attachments: HBASE-16848.master.001.patch, 
> HBASE-16848.master.001.patch
>
>
> {code}
> hbase(main):003:0> show_peer_tableCFs
> ERROR: wrong number of arguments (0 for 1)
> Here is some help for this command:
>   Show replicable table-cf config for the specified peer.
> hbase> show_peer_tableCFs
> {code}
> The sample usage should include peer id.



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

[jira] [Commented] (HBASE-19504) Add TimeRange support into checkAndMutate

[Hudson (JIRA)]

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

Hudson commented on HBASE-19504:


Results for branch master
[build #271 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/271/]: (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/master/271//General_Nightly_Build_Report/]




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


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


> Add TimeRange support into checkAndMutate
> -
>
> Key: HBASE-19504
> URL: https://issues.apache.org/jira/browse/HBASE-19504
> Project: HBase
>  Issue Type: New Feature
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-19504.v0.patch
>
>




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

[jira] [Commented] (HBASE-13300) Fix casing in getTimeStamp() and setTimestamp() for Mutations

[Hudson (JIRA)]

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

Hudson commented on HBASE-13300:


Results for branch master
[build #271 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/271/]: (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/master/271//General_Nightly_Build_Report/]




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


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


> Fix casing in getTimeStamp() and setTimestamp() for Mutations
> -
>
> Key: HBASE-13300
> URL: https://issues.apache.org/jira/browse/HBASE-13300
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Jan Hentschel
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-13300.branch-2.001.patch, 
> HBASE-13300.branch-2.002.patch, HBASE-13300.branch-2.002.patch, 
> HBASE-13300.master.001.patch, HBASE-13300.master.002.patch, 
> HBASE-13300.master.003.patch, HBASE-13300.master.003.patch, 
> HBASE-13300.master.004.patch, HBASE-13300.master.005.patch, HBASE-13300.xlsx
>
>
> For some reason we have two ways of writing this method. It should be 
> consistent.



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

[jira] [Commented] (HBASE-19983) Update ref guide for hadoop versions to include 2.8 and 2.9

[Hudson (JIRA)]

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

Hudson commented on HBASE-19983:


Results for branch master
[build #271 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/271/]: (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/master/271//General_Nightly_Build_Report/]




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


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


> Update ref guide for hadoop versions to include 2.8 and 2.9
> ---
>
> Key: HBASE-19983
> URL: https://issues.apache.org/jira/browse/HBASE-19983
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation, hadoop2
>Reporter: Mike Drob
>Assignee: Sean Busbey
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-19983.0.patch
>
>




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

[jira] [Commented] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20271:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
26s{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 
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
30s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
16s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m 
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
27s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 1s{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 
16s{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 27s{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 
53s{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:green}+1{color} | {color:green} unit {color} | {color:green}157m 
38s{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}198m 27s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20271 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916045/HBASE-20271.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 20f37456b452 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 
21:23:04 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 / 64ccd2b295 |
| 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/12121/testReport/ |
| Max. process+thread count | 3986 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12121/console |
| Powered by | Apache 

[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-15291:


Another Q:

Should we check the null srcFs in failedBulkLoad? The NPE may happen if 
prepareBulkLoad() fails to instantiate the srcFs. That makes HRegion call 
failedBulkLoad and the srcFs is null.

 

> FileSystem not closed in secure bulkLoad
> 
>
> Key: HBASE-15291
> URL: https://issues.apache.org/jira/browse/HBASE-15291
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.0.2, 0.98.16.1
>Reporter: Yong Zhang
>Assignee: Ashish Singhi
>Priority: Major
> Attachments: HBASE-15291-revert-master.patch, HBASE-15291.001.patch, 
> HBASE-15291.002.patch, HBASE-15291.003.patch, HBASE-15291.004.patch, 
> HBASE-15291.addendum, HBASE-15291.patch, HBASE-15291.v1.patch, patch
>
>
> FileSystem not closed in secure bulkLoad after bulkLoad  finish, it will 
> cause memory used more and more if too many bulkLoad .



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

[jira] [Commented] (HBASE-20261) Table page (table.jsp) in Master UI does not show replicaIds for hbase meta table

[Hudson (JIRA)]

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

Hudson commented on HBASE-20261:


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




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


> Table page (table.jsp) in Master UI does not show replicaIds for hbase meta 
> table
> -
>
> Key: HBASE-20261
> URL: https://issues.apache.org/jira/browse/HBASE-20261
> Project: HBase
>  Issue Type: Bug
>  Components: UI
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Fix For: 1.5.0, 2.0.0
>
> Attachments: HBASE-20261.master.001.patch, Screen Shot 2018-03-23 at 
> 12.05.27.png
>
>
> When region replication is enabled for hbase meta table, the table page 
> (table.jsp) in Master UI does not show replicaIds for hbase meta table. It 
> only shows the header:
> !Screen Shot 2018-03-23 at 12.05.27.png! 



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

[jira] [Commented] (HBASE-16848) Usage for show_peer_tableCFs command doesn't include peer

[Hudson (JIRA)]

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

Hudson commented on HBASE-16848:


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




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


> Usage for show_peer_tableCFs command doesn't include peer
> -
>
> Key: HBASE-16848
> URL: https://issues.apache.org/jira/browse/HBASE-16848
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Peter Somogyi
>Priority: Minor
>  Labels: documentation, replication, shell
> Fix For: 3.0.0, 2.1.0, 1.5.0, 1.2.7, 1.4.3, 2.0.0
>
> Attachments: HBASE-16848.master.001.patch, 
> HBASE-16848.master.001.patch
>
>
> {code}
> hbase(main):003:0> show_peer_tableCFs
> ERROR: wrong number of arguments (0 for 1)
> Here is some help for this command:
>   Show replicable table-cf config for the specified peer.
> hbase> show_peer_tableCFs
> {code}
> The sample usage should include peer id.



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

[jira] [Commented] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20227:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
32s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  4s{color} 
| {color:red} HBASE-20227 does not apply to master. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20227 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916055/HBASE-20227.master.007.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12125/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch, HBASE-20227.master.006.patch, 
> HBASE-20227.master.007.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Commented] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20227:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
32s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  4s{color} 
| {color:red} HBASE-20227 does not apply to master. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20227 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916055/HBASE-20227.master.007.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12124/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch, HBASE-20227.master.006.patch, 
> HBASE-20227.master.007.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Jingyun Tian (JIRA)]

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

Jingyun Tian updated HBASE-20227:
-
Attachment: HBASE-20227.master.007.patch

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch, HBASE-20227.master.006.patch, 
> HBASE-20227.master.007.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Jingyun Tian (JIRA)]

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

Jingyun Tian updated HBASE-20227:
-
Attachment: HBASE-20227.master.006.patch

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch, HBASE-20227.master.006.patch, 
> HBASE-20227.master.007.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Commented] (HBASE-20093) Replace ServerLoad by ServerMetrics for ServerManager

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-20093:


[~stack] I run the perf with/without this patch. I can't observe obvious 
degradation about the request per second. Could you post more infos about your 
observation for me? Thanks.

> Replace ServerLoad by ServerMetrics for ServerManager
> -
>
> Key: HBASE-20093
> URL: https://issues.apache.org/jira/browse/HBASE-20093
> Project: HBase
>  Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20093.addendum.patch, HBASE-20093.v0.patch, 
> HBASE-20093.v1.patch
>
>




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

[jira] [Commented] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20227:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
32s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  4s{color} 
| {color:red} HBASE-20227 does not apply to master. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20227 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916053/HBASE-20227.master.005.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12123/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Jingyun Tian (JIRA)]

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

Jingyun Tian updated HBASE-20227:
-
Attachment: HBASE-20227.master.005.patch

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.005.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Jingyun Tian (JIRA)]

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

Jingyun Tian updated HBASE-20227:
-
Attachment: (was: HBASE-20227.master.004.patch)

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15291:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
24s{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 
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
11s{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 
47s{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 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
57s{color} | {color:green} hbase-server: The patch generated 0 new + 3 
unchanged - 1 fixed = 3 total (was 4) {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 
 7s{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 16s{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  
4s{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}158m 31s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
17s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}199m  7s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestReplicaWithCluster |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-15291 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916042/HBASE-15291.v1.patch |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 80e62b4f153c 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 
11:50:30 UTC 2017 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 / 64ccd2b295 |
| 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/12119/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 

[jira] [Commented] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20227:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
34s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red}  0m  4s{color} 
| {color:red} HBASE-20227 does not apply to master. Rebase required? Wrong 
Branch? See https://yetus.apache.org/documentation/0.7.0/precommit-patchnames 
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20227 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916052/HBASE-20227.master.004.patch
 |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12122/console |
| Powered by | Apache Yetus 0.7.0   http://yetus.apache.org |


This message was automatically generated.



> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.004.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Updated] (HBASE-20227) Add UT for ReplicationUtils.contains method

[Jingyun Tian (JIRA)]

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

Jingyun Tian updated HBASE-20227:
-
Attachment: HBASE-20227.master.004.patch

> Add UT for ReplicationUtils.contains method
> ---
>
> Key: HBASE-20227
> URL: https://issues.apache.org/jira/browse/HBASE-20227
> Project: HBase
>  Issue Type: Sub-task
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Jingyun Tian
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20227.master.001.patch, 
> HBASE-20227.master.002.patch, HBASE-20227.master.003.patch, 
> HBASE-20227.master.004.patch
>
>
> The method is extracted from NamespaceTableCfWALEntryFilter. But 
> NamespaceTableCfWALEntryFilter is in the hbase-server module so the UTs which 
> tests the function of this method are also in the hbase-server module. If 
> later we modify ReplicationUtils.contains without touching any code in 
> hbase-server, then we will not run the UTs for this method and may introduce 
> bugs.



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

[jira] [Commented] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20280:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m  
9s{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}  7m 
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
 0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  5m 
 8s{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 
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
35s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
 8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  1m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  1m 
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
10s{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 57s{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 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}111m 
48s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
21s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}155m 52s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20280 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916041/HBASE-20280.master.001.patch
 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 5c3fe1ab93a0 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 / 64ccd2b295 |
| 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/12120/testReport/ |
| Max. process+thread count | 4553 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/12120/console |
| Powered by 

[jira] [Commented] (HBASE-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-20272:


+1 

It is my mistake. Previous QA retried the failed test with single parameter so 
it passed...

> TestAsyncTable#testCheckAndMutateWithTimeRange fails due to 
> TableExistsException
> 
>
> Key: HBASE-20272
> URL: https://issues.apache.org/jira/browse/HBASE-20272
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20272.v1.txt, 20272.v2.txt
>
>
> The following test failure is reproducible:
> {code}
> org.apache.hadoop.hbase.TableExistsException: testCheckAndMutateWithTimeRange
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:233)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:87)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:51)
>  at 
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:184)
>  at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:845)
>  at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1453)
> {code}
> The cause was that TestAsyncTable is parameterized while the 
> testCheckAndMutateWithTimeRange uses the same table name without dropping the 
> table after the first invocation finishes.
> This leads to second invocation failing with TableExistsException.



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

[jira] [Updated] (HBASE-19704) region split happened when it contains reference file

[chenxu (JIRA)]

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

chenxu updated HBASE-19704:
---
Description: 
In our prod env, some Region’s dir contains reference file, but it also 
splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit()'s 
constraint, and CatalogJanitor can’t collect it.
 I suspect it was due to HBASE-13082 which we recently introduced, after 
introduce this feature, the compacted files were remove asynchronously. when 
region split happens and HStore#close() execute, if compactedfiles can’t 
satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it will 
be always exist.

  was:
In our prod env, some Region’s dir contains reference file, but it also 
splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit()'s 
constraint, and CatalogJanitor can’t collect it.
 I suspect it was due to HBASE-13082 which we recently introduced, after 
introduce this feature, the comapcted files were removed asynchronously. when 
region split happens and HStore#close() execute, if compactedfiles can’t 
satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it will 
be always exist.


> region split happened when it contains reference file
> -
>
> Key: HBASE-19704
> URL: https://issues.apache.org/jira/browse/HBASE-19704
> Project: HBase
>  Issue Type: Bug
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: HBASE-19704-master-v1.patch
>
>
> In our prod env, some Region’s dir contains reference file, but it also 
> splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit()'s 
> constraint, and CatalogJanitor can’t collect it.
>  I suspect it was due to HBASE-13082 which we recently introduced, after 
> introduce this feature, the compacted files were remove asynchronously. when 
> region split happens and HStore#close() execute, if compactedfiles can’t 
> satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it 
> will be always exist.



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

[jira] [Updated] (HBASE-19704) region split happened when it contains reference file

[chenxu (JIRA)]

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

chenxu updated HBASE-19704:
---
Description: 
In our prod env, some Region’s dir contains reference file, but it also 
splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit()'s 
constraint, and CatalogJanitor can’t collect it.
 I suspect it was due to HBASE-13082 which we recently introduced, after 
introduce this feature, the comapcted files were removed asynchronously. when 
region split happens and HStore#close() execute, if compactedfiles can’t 
satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it will 
be always exist.

  was:
In our prod env, some Region’s dir contains reference file, but it also 
splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit() method, and 
CatalogJanitor can’t collect it.
 I suspect it was due to HBASE-13082 which we recently introduced, after 
introduce this feature, the comapcted files were removed asynchronously. when 
region split happens and HStore#close() execute, if compactedfiles can’t 
satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it will 
be always exist.


> region split happened when it contains reference file
> -
>
> Key: HBASE-19704
> URL: https://issues.apache.org/jira/browse/HBASE-19704
> Project: HBase
>  Issue Type: Bug
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: HBASE-19704-master-v1.patch
>
>
> In our prod env, some Region’s dir contains reference file, but it also 
> splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit()'s 
> constraint, and CatalogJanitor can’t collect it.
>  I suspect it was due to HBASE-13082 which we recently introduced, after 
> introduce this feature, the comapcted files were removed asynchronously. when 
> region split happens and HStore#close() execute, if compactedfiles can’t 
> satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it 
> will be always exist.



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

[jira] [Updated] (HBASE-19704) region split happened when it contains reference file

[chenxu (JIRA)]

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

chenxu updated HBASE-19704:
---
Description: 
In our prod env, some Region’s dir contains reference file, but it also 
splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit() method, and 
CatalogJanitor can’t collect it.
 I suspect it was due to HBASE-13082 which we recently introduced, after 
introduce this feature, the comapcted files were removed asynchronously. when 
region split happens and HStore#close() execute, if compactedfiles can’t 
satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it will 
be always exist.

  was:
In our product cluster, some Region’s dir contains reference file, but it also 
splited, that's violate ConstantSizeRegionSplitPolicy.shouldSplit() method, and 
CatalogJanitor can’t collect it.
I suspect it was due to HBASE-13082 which we recently introduced, after 
introduce this feature, the comapcted files were removed asynchronously. when 
region split happens and HStore.close() execute, if compactedfiles can’t 
satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it will 
be always exist.


> region split happened when it contains reference file
> -
>
> Key: HBASE-19704
> URL: https://issues.apache.org/jira/browse/HBASE-19704
> Project: HBase
>  Issue Type: Bug
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: HBASE-19704-master-v1.patch
>
>
> In our prod env, some Region’s dir contains reference file, but it also 
> splited, that's violate ConstantSizeRegionSplitPolicy#shouldSplit() method, 
> and CatalogJanitor can’t collect it.
>  I suspect it was due to HBASE-13082 which we recently introduced, after 
> introduce this feature, the comapcted files were removed asynchronously. when 
> region split happens and HStore#close() execute, if compactedfiles can’t 
> satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it 
> will be always exist.



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

[jira] [Commented] (HBASE-19704) region split happened when it contains reference file

[chenxu (JIRA)]

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

chenxu commented on HBASE-19704:


we need close the changedReadersObservers first when do HStore#close()
so the refCount of the target file can be reduced

> region split happened when it contains reference file
> -
>
> Key: HBASE-19704
> URL: https://issues.apache.org/jira/browse/HBASE-19704
> Project: HBase
>  Issue Type: Bug
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: HBASE-19704-master-v1.patch
>
>
> In our product cluster, some Region’s dir contains reference file, but it 
> also splited, that's violate ConstantSizeRegionSplitPolicy.shouldSplit() 
> method, and CatalogJanitor can’t collect it.
> I suspect it was due to HBASE-13082 which we recently introduced, after 
> introduce this feature, the comapcted files were removed asynchronously. when 
> region split happens and HStore.close() execute, if compactedfiles can’t 
> satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it 
> will be always exist.



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

[jira] [Updated] (HBASE-19704) region split happened when it contains reference file

[chenxu (JIRA)]

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

chenxu updated HBASE-19704:
---
Attachment: HBASE-19704-master-v1.patch

> region split happened when it contains reference file
> -
>
> Key: HBASE-19704
> URL: https://issues.apache.org/jira/browse/HBASE-19704
> Project: HBase
>  Issue Type: Bug
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
> Attachments: HBASE-19704-master-v1.patch
>
>
> In our product cluster, some Region’s dir contains reference file, but it 
> also splited, that's violate ConstantSizeRegionSplitPolicy.shouldSplit() 
> method, and CatalogJanitor can’t collect it.
> I suspect it was due to HBASE-13082 which we recently introduced, after 
> introduce this feature, the comapcted files were removed asynchronously. when 
> region split happens and HStore.close() execute, if compactedfiles can’t 
> satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it 
> will be always exist.



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

[jira] [Commented] (HBASE-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[Ted Yu (JIRA)]

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

Ted Yu commented on HBASE-20272:


[~chia7712]chia-ping:
Can you take a look as well ?

> TestAsyncTable#testCheckAndMutateWithTimeRange fails due to 
> TableExistsException
> 
>
> Key: HBASE-20272
> URL: https://issues.apache.org/jira/browse/HBASE-20272
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20272.v1.txt, 20272.v2.txt
>
>
> The following test failure is reproducible:
> {code}
> org.apache.hadoop.hbase.TableExistsException: testCheckAndMutateWithTimeRange
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:233)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:87)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:51)
>  at 
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:184)
>  at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:845)
>  at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1453)
> {code}
> The cause was that TestAsyncTable is parameterized while the 
> testCheckAndMutateWithTimeRange uses the same table name without dropping the 
> table after the first invocation finishes.
> This leads to second invocation failing with TableExistsException.



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

[jira] [Assigned] (HBASE-19704) region split happened when it contains reference file

[chenxu (JIRA)]

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

chenxu reassigned HBASE-19704:
--

Assignee: chenxu

> region split happened when it contains reference file
> -
>
> Key: HBASE-19704
> URL: https://issues.apache.org/jira/browse/HBASE-19704
> Project: HBase
>  Issue Type: Bug
>Reporter: chenxu
>Assignee: chenxu
>Priority: Major
>
> In our product cluster, some Region’s dir contains reference file, but it 
> also splited, that's violate ConstantSizeRegionSplitPolicy.shouldSplit() 
> method, and CatalogJanitor can’t collect it.
> I suspect it was due to HBASE-13082 which we recently introduced, after 
> introduce this feature, the comapcted files were removed asynchronously. when 
> region split happens and HStore.close() execute, if compactedfiles can’t 
> satisfy (r != null && r.isCompactedAway() && !r.isReferencedInReads()) it 
> will be always exist.



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

[jira] [Commented] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Ted Yu (JIRA)]

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

Ted Yu commented on HBASE-20271:


+1

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20271.patch
>
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> 

[jira] [Updated] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-20271:
--
Component/s: Replication

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Bug
>  Components: Replication
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20271.patch
>
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> 

[jira] [Updated] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Duo Zhang (JIRA)]

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

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

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Bug
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20271.patch
>
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> 

[jira] [Updated] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Duo Zhang (JIRA)]

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

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

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Bug
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20271.patch
>
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 

[jira] [Commented] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-20271:
---

When hitting FNFE in WALEntryStream we will try to open the wal in the archive 
directory. Used to think this will not effect the current path in 
WALEntryStream since it is always peeked from the logQueue, but after 
re-reading the code I found that it is wrong. We will set current path in 
openReader and in handleFileNotFound we will pass the archived path into 
openReader so the current path will be changed.

Let me prepare a patch to fix it.

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Bug
>Reporter: Duo Zhang
>Priority: Major
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at 

[jira] [Updated] (HBASE-20271) ReplicationSourceWALReader.switched should use the file name instead of the path object directly

[Duo Zhang (JIRA)]

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

Duo Zhang updated HBASE-20271:
--
Summary: ReplicationSourceWALReader.switched should use the file name 
instead of the path object directly  (was: 
TestReplicaWithCluster.testReplicaAndReplication sometimes fails when calling 
setWALPosition)

> ReplicationSourceWALReader.switched should use the file name instead of the 
> path object directly
> 
>
> Key: HBASE-20271
> URL: https://issues.apache.org/jira/browse/HBASE-20271
> Project: HBase
>  Issue Type: Bug
>Reporter: Duo Zhang
>Priority: Major
>
> {noformat}
> 2018-03-24 08:29:29,965 ERROR 
> [RS_REFRESH_PEER-regionserver/ubuntu:0-0.replicationSource,2.replicationSource.shipperubuntu%2C35197%2C1521851267085,2]
>  helpers.MarkerIgnoringBase(159): * ABORTING region server 
> ubuntu,35197,1521851267085: Failed to operate on replication queue *
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:235)
>   ... 6 more
> 2018-03-24 08:29:30,025 ERROR 
> [RpcServer.default.FPBQ.Fifo.handler=2,queue=0,port=37509] 
> master.MasterRpcServices(508): Region server ubuntu,35197,1521851267085 
> reported a fatal error:
> * ABORTING region server ubuntu,35197,1521851267085: Failed to operate on 
> replication queue *
> Cause:
> org.apache.hadoop.hbase.replication.ReplicationException: Failed to set log 
> position (serverName=ubuntu,35197,1521851267085, queueId=2, 
> fileName=ubuntu%2C35197%2C1521851267085.1521851344947, position=2533)
>   at 
> org.apache.hadoop.hbase.replication.ZKReplicationQueueStorage.setWALPosition(ZKReplicationQueueStorage.java:237)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.lambda$9(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.abortWhenFail(ReplicationSourceManager.java:455)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceManager.logPositionAndCleanOldLogs(ReplicationSourceManager.java:488)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.updateLogPosition(ReplicationSourceShipper.java:232)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.shipEdits(ReplicationSourceShipper.java:134)
>   at 
> org.apache.hadoop.hbase.replication.regionserver.ReplicationSourceShipper.run(ReplicationSourceShipper.java:104)
> Caused by: org.apache.zookeeper.KeeperException$NoNodeException: 
> KeeperErrorCode = NoNode
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:111)
>   at org.apache.zookeeper.ZooKeeper.multiInternal(ZooKeeper.java:1006)
>   at org.apache.zookeeper.ZooKeeper.multi(ZooKeeper.java:910)
>   at 
> org.apache.hadoop.hbase.zookeeper.RecoverableZooKeeper.multi(RecoverableZooKeeper.java:663)
>   at 
> org.apache.hadoop.hbase.zookeeper.ZKUtil.multiOrSequential(ZKUtil.java:1670)
>   at 
> 

[jira] [Commented] (HBASE-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-20272:
---

+1.

> TestAsyncTable#testCheckAndMutateWithTimeRange fails due to 
> TableExistsException
> 
>
> Key: HBASE-20272
> URL: https://issues.apache.org/jira/browse/HBASE-20272
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Major
> Attachments: 20272.v1.txt, 20272.v2.txt
>
>
> The following test failure is reproducible:
> {code}
> org.apache.hadoop.hbase.TableExistsException: testCheckAndMutateWithTimeRange
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.prepareCreate(CreateTableProcedure.java:233)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:87)
>  at 
> org.apache.hadoop.hbase.master.procedure.CreateTableProcedure.executeFromState(CreateTableProcedure.java:51)
>  at 
> org.apache.hadoop.hbase.procedure2.StateMachineProcedure.execute(StateMachineProcedure.java:184)
>  at org.apache.hadoop.hbase.procedure2.Procedure.doExecute(Procedure.java:845)
>  at 
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1453)
> {code}
> The cause was that TestAsyncTable is parameterized while the 
> testCheckAndMutateWithTimeRange uses the same table name without dropping the 
> table after the first invocation finishes.
> This leads to second invocation failing with TableExistsException.



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

[jira] [Comment Edited] (HBASE-20093) Replace ServerLoad by ServerMetrics for ServerManager

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai edited comment on HBASE-20093 at 3/24/18 7:56 AM:
-

{quote}Do you think this changed how we calculate the request per second in the 
UI? Just wondering. hbase2 does less requests, probably because it is slower, 
but perhaps the change here made a difference too?{quote}
All request count get smaller? I will check it later.


was (Author: chia7712):
{quote}Do you think this changed how we calculate the request per second in the 
UI? 
{quote}
How about using 
[ServerMetrics#getRequestCountPerSecond|https://github.com/apache/hbase/blob/master/hbase-client/src/main/java/org/apache/hadoop/hbase/ServerMetrics.java#L38]
{quote}Just wondering. hbase2 does less requests, probably because it is 
slower, but perhaps the change here made a difference too?
{quote}
All request count get smaller? I will check it later.

> Replace ServerLoad by ServerMetrics for ServerManager
> -
>
> Key: HBASE-20093
> URL: https://issues.apache.org/jira/browse/HBASE-20093
> Project: HBase
>  Issue Type: Task
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20093.addendum.patch, HBASE-20093.v0.patch, 
> HBASE-20093.v1.patch
>
>




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

[jira] [Commented] (HBASE-20272) TestAsyncTable#testCheckAndMutateWithTimeRange fails due to TableExistsException

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-20272:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
37s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue}  0m  
1s{color} | {color:blue} The patch file was not named according to hbase's 
naming conventions. Please see 
https://yetus.apache.org/documentation/0.7.0/precommit-patchnames for 
instructions. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
51s{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 
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  6m 
30s{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 
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
38s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  5m 
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m  
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m  
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
21s{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 
11s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
20m 42s{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 
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}110m 10s{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}161m 39s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.replication.TestReplicationDroppedTables |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:eee3b01 |
| JIRA Issue | HBASE-20272 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12916028/20272.v2.txt |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  shadedjars  
hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 73efe65c8ab3 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 / 64ccd2b295 |
| 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 | 

[jira] [Commented] (HBASE-20130) Document the ports used by RS are changed to 16201/16301 when the RS is bound to localhost

[Chia-Ping Tsai (JIRA)]

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

Chia-Ping Tsai commented on HBASE-20130:


{quote}I think leaving the hard coded non-default ports as is, will make it 
necessary to document this exception and may cause more confusion. We need to 
use default ports which allows up to 10 instances of region servers and if 
somebody wants to have more, it can be done by changing the ports as needed in 
these files. This can be documented in ref guide.
{quote}
I also prefer the old port number since the ports used in hbase cluster are 
inconsistent between different script. For example, we can start a standalone 
hbase cluster by start-hbase.sh or hbase-daemon.sh.  The ports bound by former 
are 1620x/1630x. The ports, by contrast, bound by later are 1602x/1603x.

> Document the ports used by RS are changed to 16201/16301 when the RS is bound 
> to localhost
> --
>
> Key: HBASE-20130
> URL: https://issues.apache.org/jira/browse/HBASE-20130
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Chia-Ping Tsai
>Assignee: Umesh Agashe
>Priority: Critical
> Fix For: 2.0.0
>
>




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

[jira] [Commented] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled

[Zach York (JIRA)]

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

Zach York commented on HBASE-20280:
---

[~apurtell] Could you make sure I am understanding the prefetch logic correctly 
(especially around canceling)? Trying to understand the code, it looks like 
when a ClosedByInterruptException is thrown it first sets the thread to 
interrupted then throws the exception.

>From 
>[https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderImpl.java#L270]
> it looks like after the exception is thrown (and caught by BucketCache) this 
>should break out of the loop. However, I saw two exceptions being thrown back 
>to back by apparently the same thread (by name at least) which would indicate 
>that this didn't actually break out of the loop. Do you have any idea what is 
>going on here:

 

2018-03-17 12:03:31,986 ERROR [hfile-prefetch-1521244956862] 
bucket.BucketCache: Failed reading block 
f1512d0ed56546939771d8e7f5e72c6a_129839 from bucket cache 
java.nio.channels.ClosedByInterruptException at 
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
 at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:746) at 
sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:727) at 
org.apache.hadoop.hbase.io.hfile.bucket.FileIOEngine$FileReadAccessor.access(FileIOEngine.java:276)
 at 
org.apache.hadoop.hbase.io.hfile.bucket.FileIOEngine.accessFile(FileIOEngine.java:196)
 at 
org.apache.hadoop.hbase.io.hfile.bucket.FileIOEngine.read(FileIOEngine.java:113)
 at 
org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.getBlock(BucketCache.java:506)
 at 
org.apache.hadoop.hbase.io.hfile.CombinedBlockCache.getBlock(CombinedBlockCache.java:84)
 at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2.getCachedBlock(HFileReaderV2.java:279)
 at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:420)
 at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$1.run(HFileReaderV2.java:209) at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at 
java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748) 2018-03-17 12:03:31,986 ERROR 
[hfile-prefetch-1521244956862] bucket.BucketCache: Failed reading block 
f1512d0ed56546939771d8e7f5e72c6a_129839 from bucket cache 
java.nio.channels.ClosedByInterruptException at 
java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
 at sun.nio.ch.FileChannelImpl.readInternal(FileChannelImpl.java:746) at 
sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:727) at 
org.apache.hadoop.hbase.io.hfile.bucket.FileIOEngine$FileReadAccessor.access(FileIOEngine.java:276)
 at 
org.apache.hadoop.hbase.io.hfile.bucket.FileIOEngine.accessFile(FileIOEngine.java:196)
 at 
org.apache.hadoop.hbase.io.hfile.bucket.FileIOEngine.read(FileIOEngine.java:113)
 at 
org.apache.hadoop.hbase.io.hfile.bucket.BucketCache.getBlock(BucketCache.java:506)
 at 
org.apache.hadoop.hbase.io.hfile.CombinedBlockCache.getBlock(CombinedBlockCache.java:84)
 at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2.getCachedBlock(HFileReaderV2.java:279)
 at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2.readBlock(HFileReaderV2.java:420)
 at 
org.apache.hadoop.hbase.io.hfile.HFileReaderV2$1.run(HFileReaderV2.java:209) at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at 
java.util.concurrent.FutureTask.run(FutureTask.java:266) at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
 at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748)

> Fix possibility of deadlocking in refreshFileConnections when prefetch is 
> enabled
> -
>
> Key: HBASE-20280
> URL: https://issues.apache.org/jira/browse/HBASE-20280
> Project: HBase
>  Issue Type: Bug
>  Components: BucketCache
>Affects Versions: 2.0.0-beta-2, 1.4.2
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
>

[jira] [Commented] (HBASE-15291) FileSystem not closed in secure bulkLoad

[Ashish Singhi (JIRA)]

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

Ashish Singhi commented on HBASE-15291:
---

Thanks [~chia7712] for taking a look. I have addressed your comment.
Please take a look.

> FileSystem not closed in secure bulkLoad
> 
>
> Key: HBASE-15291
> URL: https://issues.apache.org/jira/browse/HBASE-15291
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.0.2, 0.98.16.1
>Reporter: Yong Zhang
>Assignee: Ashish Singhi
>Priority: Major
> Attachments: HBASE-15291-revert-master.patch, HBASE-15291.001.patch, 
> HBASE-15291.002.patch, HBASE-15291.003.patch, HBASE-15291.004.patch, 
> HBASE-15291.addendum, HBASE-15291.patch, HBASE-15291.v1.patch, patch
>
>
> FileSystem not closed in secure bulkLoad after bulkLoad  finish, it will 
> cause memory used more and more if too many bulkLoad .



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

[jira] [Updated] (HBASE-15291) FileSystem not closed in secure bulkLoad

[Ashish Singhi (JIRA)]

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

Ashish Singhi updated HBASE-15291:
--
Attachment: HBASE-15291.v1.patch

> FileSystem not closed in secure bulkLoad
> 
>
> Key: HBASE-15291
> URL: https://issues.apache.org/jira/browse/HBASE-15291
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.0.2, 0.98.16.1
>Reporter: Yong Zhang
>Assignee: Ashish Singhi
>Priority: Major
> Attachments: HBASE-15291-revert-master.patch, HBASE-15291.001.patch, 
> HBASE-15291.002.patch, HBASE-15291.003.patch, HBASE-15291.004.patch, 
> HBASE-15291.addendum, HBASE-15291.patch, HBASE-15291.v1.patch, patch
>
>
> FileSystem not closed in secure bulkLoad after bulkLoad  finish, it will 
> cause memory used more and more if too many bulkLoad .



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

[jira] [Updated] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled

[Zach York (JIRA)]

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

Zach York updated HBASE-20280:
--
Status: Patch Available  (was: Open)

> Fix possibility of deadlocking in refreshFileConnections when prefetch is 
> enabled
> -
>
> Key: HBASE-20280
> URL: https://issues.apache.org/jira/browse/HBASE-20280
> Project: HBase
>  Issue Type: Bug
>  Components: BucketCache
>Affects Versions: 1.4.2, 2.0.0-beta-2
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
> Attachments: HBASE-20280.master.001.patch
>
>
> When prefetch on open is specified, there is a deadlocking case
> where if the prefetch is cancelled, the PrefetchExecutor interrupts
> the threads if necessary, when that happens in FileIOEngine, it
> causes an ClosedByInterruptException which is a subclass of
> ClosedChannelException. If we retry all ClosedChannelExceptions,
> this will lock as this access is expected to be interrupted.
> This change removes calling refreshFileConnections for
> ClosedByInterruptExceptions.



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

[jira] [Updated] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled

[Zach York (JIRA)]

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

Zach York updated HBASE-20280:
--
Attachment: HBASE-20280.master.001.patch

> Fix possibility of deadlocking in refreshFileConnections when prefetch is 
> enabled
> -
>
> Key: HBASE-20280
> URL: https://issues.apache.org/jira/browse/HBASE-20280
> Project: HBase
>  Issue Type: Bug
>  Components: BucketCache
>Affects Versions: 2.0.0-beta-2, 1.4.2
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
> Attachments: HBASE-20280.master.001.patch
>
>
> When prefetch on open is specified, there is a deadlocking case
> where if the prefetch is cancelled, the PrefetchExecutor interrupts
> the threads if necessary, when that happens in FileIOEngine, it
> causes an ClosedByInterruptException which is a subclass of
> ClosedChannelException. If we retry all ClosedChannelExceptions,
> this will lock as this access is expected to be interrupted.
> This change removes calling refreshFileConnections for
> ClosedByInterruptExceptions.



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

[jira] [Created] (HBASE-20280) Fix possibility of deadlocking in refreshFileConnections when prefetch is enabled

[Zach York (JIRA)]

Zach York created HBASE-20280:
-

 Summary: Fix possibility of deadlocking in refreshFileConnections 
when prefetch is enabled
 Key: HBASE-20280
 URL: https://issues.apache.org/jira/browse/HBASE-20280
 Project: HBase
  Issue Type: Bug
  Components: BucketCache
Affects Versions: 1.4.2, 2.0.0-beta-2
Reporter: Zach York
Assignee: Zach York


When prefetch on open is specified, there is a deadlocking case
where if the prefetch is cancelled, the PrefetchExecutor interrupts
the threads if necessary, when that happens in FileIOEngine, it
causes an ClosedByInterruptException which is a subclass of
ClosedChannelException. If we retry all ClosedChannelExceptions,
this will lock as this access is expected to be interrupted.
This change removes calling refreshFileConnections for
ClosedByInterruptExceptions.



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

[jira] [Commented] (HBASE-20245) HTrace commands do not work

[Hudson (JIRA)]

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

Hudson commented on HBASE-20245:


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


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


> HTrace commands do not work
> ---
>
> Key: HBASE-20245
> URL: https://issues.apache.org/jira/browse/HBASE-20245
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Balazs Meszaros
>Assignee: Balazs Meszaros
>Priority: Major
> Fix For: 2.0.0
>
> Attachments: HBASE-20245.master.001.patch
>
>
> When running shell-2.0 against server-2.0 we get the following error:
> {code}
> hbase(main):034:0> trace 'start'
> ERROR: undefined method `isTracing' for 
> Java::OrgApacheHtraceCore::Tracer:Class
> {code}
> It is possible to manipulate tracing from shell-1.2.



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

[jira] [Commented] (HBASE-13300) Fix casing in getTimeStamp() and setTimestamp() for Mutations

[Hudson (JIRA)]

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

Hudson commented on HBASE-13300:


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


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


> Fix casing in getTimeStamp() and setTimestamp() for Mutations
> -
>
> Key: HBASE-13300
> URL: https://issues.apache.org/jira/browse/HBASE-13300
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Affects Versions: 1.0.0
>Reporter: Lars George
>Assignee: Jan Hentschel
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-13300.branch-2.001.patch, 
> HBASE-13300.branch-2.002.patch, HBASE-13300.branch-2.002.patch, 
> HBASE-13300.master.001.patch, HBASE-13300.master.002.patch, 
> HBASE-13300.master.003.patch, HBASE-13300.master.003.patch, 
> HBASE-13300.master.004.patch, HBASE-13300.master.005.patch, HBASE-13300.xlsx
>
>
> For some reason we have two ways of writing this method. It should be 
> consistent.



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

[jira] [Commented] (HBASE-20135) NullPointerException during reading bloom filter when upgraded from hbase-1 to hbase-2

[Hudson (JIRA)]

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

Hudson commented on HBASE-20135:


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


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


> NullPointerException during reading bloom filter when upgraded from hbase-1 
> to hbase-2
> --
>
> Key: HBASE-20135
> URL: https://issues.apache.org/jira/browse/HBASE-20135
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0-beta-2
>Reporter: Umesh Agashe
>Assignee: Sakthi
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: hbase-20135.master.001.patch, 
> hbase-20135.master.002.patch
>
>
> When upgraded from hbase-1 to hbase-2, found following exception logged 
> multiple times in the log:
> {code:java}
> ERROR [StoreFileOpenerThread-test_cf-1] regionserver.StoreFileReader: Error 
> reading bloom filter meta for GENERAL_BLOOM_META -- proceeding without
> java.io.IOException: Comparator class 
> org.apache.hadoop.hbase.KeyValue$RawBytesComparator is not instantiable
>         at 
> org.apache.hadoop.hbase.io.hfile.FixedFileTrailer.createComparator(FixedFileTrailer.java:628)
>         at 
> org.apache.hadoop.hbase.io.hfile.CompoundBloomFilter.(CompoundBloomFilter.java:79)
>         at 
> org.apache.hadoop.hbase.util.BloomFilterFactory.createFromMeta(BloomFilterFactory.java:104)
>         at 
> org.apache.hadoop.hbase.regionserver.StoreFileReader.loadBloomfilter(StoreFileReader.java:479)
>         at 
> org.apache.hadoop.hbase.regionserver.HStoreFile.open(HStoreFile.java:425)
>         at 
> org.apache.hadoop.hbase.regionserver.HStoreFile.initReader(HStoreFile.java:460)
>         at 
> org.apache.hadoop.hbase.regionserver.HStore.createStoreFileAndReader(HStore.java:671)
>         at 
> org.apache.hadoop.hbase.regionserver.HStore.lambda$openStoreFiles$0(HStore.java:537)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>         at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>         at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NullPointerException{code}
>  
> Analysis from [~anoop.hbase]:
> Checking the related code.  There seems no issue..  We are not going
> to even fail reading the bloom.  In 2.0 code base we expect the
> comparator class name to be null.  But in 1.x we write old KV based
> Raw Bytes comparator class name.  So reading that back, we will return
> class name as null and we get NPE it looks like.
> {code:java}
>  else if 
> (comparatorClassName.equals("org.apache.hadoop.hbase.KeyValue$RawBytesComparator")
>         || 
> comparatorClassName.equals("org.apache.hadoop.hbase.util.Bytes$ByteArrayComparator"))
> {
>       // When the comparator to be used is Bytes.BYTES_RAWCOMPARATOR,
> we just return null from here
>       // Bytes.BYTES_RAWCOMPARATOR is not a CellComparator
>       comparatorKlass = null;
>     }
> {code}
> We can better do a null check before trying the comparator class
> instantiation so that we can avoid this scary error logs



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

[jira] [Commented] (HBASE-20261) Table page (table.jsp) in Master UI does not show replicaIds for hbase meta table

[Hudson (JIRA)]

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

Hudson commented on HBASE-20261:


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


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


> Table page (table.jsp) in Master UI does not show replicaIds for hbase meta 
> table
> -
>
> Key: HBASE-20261
> URL: https://issues.apache.org/jira/browse/HBASE-20261
> Project: HBase
>  Issue Type: Bug
>  Components: UI
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Minor
> Fix For: 1.5.0, 2.0.0
>
> Attachments: HBASE-20261.master.001.patch, Screen Shot 2018-03-23 at 
> 12.05.27.png
>
>
> When region replication is enabled for hbase meta table, the table page 
> (table.jsp) in Master UI does not show replicaIds for hbase meta table. It 
> only shows the header:
> !Screen Shot 2018-03-23 at 12.05.27.png! 



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