[jira] [Commented] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Duo Zhang (JIRA)

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

Duo Zhang commented on HBASE-17595:
---

The failed UTs seems unrelated and can pass locally.

Will commit shortly.

> Add partial result support for small/limited scan
> -
>
> Key: HBASE-17595
> URL: https://issues.apache.org/jira/browse/HBASE-17595
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17595-branch-1.patch, HBASE-17595.patch, 
> HBASE-17595-v1.patch
>
>
> The partial result support is marked as a 'TODO' when implementing 
> HBASE-17045. And when implementing HBASE-17508, we found that if we make 
> small scan share the same logic with general scan, the scan request other 
> than open scanner will not have the small flag so the server may return  
> partial result to the client and cause some strange behavior. It is solved by 
> modifying the logic at server side, but this means the 1.4.x client is not 
> safe to contact with earlier 1.x server. So we'd better address the problem 
> at client side. Marked as blocker as this issue should be finished before any 
> 2.x and 1.4.x releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17677:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2555 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2555/])
HBASE-17677 ServerName parsing from directory name should be more robust 
(busbey: rev 040b2f186a08222fc0a0b3bd5c97ccef9cf45368)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestWALMethods.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/wal/AbstractFSWALProvider.java


> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5, 1.1.10
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17672:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2555 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2555/])
HBASE-17672: "Grant should set access rights appropriately" test fails (tedyu: 
rev 335cde34150539c31e01b9f4ddfc89f63d147d5f)
* (edit) hbase-shell/src/test/ruby/hbase/security_admin_test.rb


> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17677:


SUCCESS: Integrated in Jenkins build HBase-1.1-JDK8 #1932 (See 
[https://builds.apache.org/job/HBase-1.1-JDK8/1932/])
HBASE-17677 Just the new tests from 'ServerName parsing from directory (busbey: 
rev 76879ded89e5ff0fb00bf9fc31bb90f0489ce2e0)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestWALMethods.java


> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5, 1.1.10
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17677:


SUCCESS: Integrated in Jenkins build HBase-1.3-IT #837 (See 
[https://builds.apache.org/job/HBase-1.3-IT/837/])
HBASE-17677 Just the new tests from 'ServerName parsing from directory (busbey: 
rev 7314575a2e734abedcf9445b1c02e6533fbc8a05)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestWALMethods.java


> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5, 1.1.10
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17677:


SUCCESS: Integrated in Jenkins build HBase-1.4 #642 (See 
[https://builds.apache.org/job/HBase-1.4/642/])
HBASE-17677 Just the new tests from 'ServerName parsing from directory (busbey: 
rev 7917314477fcbadcd761e617fdf472a262274443)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestWALMethods.java


> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5, 1.1.10
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17677:


SUCCESS: Integrated in Jenkins build HBase-1.2-JDK7 #106 (See 
[https://builds.apache.org/job/HBase-1.2-JDK7/106/])
HBASE-17677 Just the new tests from 'ServerName parsing from directory (busbey: 
rev 7314575a2e734abedcf9445b1c02e6533fbc8a05)
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/wal/TestWALMethods.java


> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5, 1.1.10
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17338) Treat Cell data size under global memstore heap size only when that Cell can not be copied to MSLAB

2017-02-22 Thread Anoop Sam John (JIRA)

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

Anoop Sam John updated HBASE-17338:
---
Status: Patch Available  (was: Open)

> Treat Cell data size under global memstore heap size only when that Cell can 
> not be copied to MSLAB
> ---
>
> Key: HBASE-17338
> URL: https://issues.apache.org/jira/browse/HBASE-17338
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-17338.patch, HBASE-17338_V2.patch, 
> HBASE-17338_V2.patch, HBASE-17338_V4.patch
>
>
> We have only data size and heap overhead being tracked globally.  Off heap 
> memstore works with off heap backed MSLAB pool.  But a cell, when added to 
> memstore, not always getting copied to MSLAB.  Append/Increment ops doing an 
> upsert, dont use MSLAB.  Also based on the Cell size, we sometimes avoid 
> MSLAB copy.  But now we track these cell data size also under the global 
> memstore data size which indicated off heap size in case of off heap 
> memstore.  For global checks for flushes (against lower/upper watermark 
> levels), we check this size against max off heap memstore size.  We do check 
> heap overhead against global heap memstore size (Defaults to 40% of xmx)  But 
> for such cells the data size also should be accounted under the heap overhead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-17595:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 10m 49s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 3 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 22s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
42s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 51s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
53s {color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
27s {color} | {color:green} branch-1 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 54s 
{color} | {color:red} hbase-server in branch-1 has 2 extant Findbugs warnings. 
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 39s 
{color} | {color:green} branch-1 passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s 
{color} | {color:green} branch-1 passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 45s 
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 45s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 52s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 52s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
54s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
28s {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} hadoopcheck {color} | {color:green} 
15m 20s {color} | {color:green} The patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m 
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s 
{color} | {color:green} the patch passed with JDK v1.8.0_121 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 50s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 95m 9s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
32s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 143m 33s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:e01ee2f |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12854124/HBASE-17595-branch-1.patch
 |
| JIRA Issue | HBASE-17595 |
| Optional Tests |  

[jira] [Updated] (HBASE-17338) Treat Cell data size under global memstore heap size only when that Cell can not be copied to MSLAB

2017-02-22 Thread Anoop Sam John (JIRA)

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

Anoop Sam John updated HBASE-17338:
---
Attachment: HBASE-17338_V4.patch

> Treat Cell data size under global memstore heap size only when that Cell can 
> not be copied to MSLAB
> ---
>
> Key: HBASE-17338
> URL: https://issues.apache.org/jira/browse/HBASE-17338
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-17338.patch, HBASE-17338_V2.patch, 
> HBASE-17338_V2.patch, HBASE-17338_V4.patch
>
>
> We have only data size and heap overhead being tracked globally.  Off heap 
> memstore works with off heap backed MSLAB pool.  But a cell, when added to 
> memstore, not always getting copied to MSLAB.  Append/Increment ops doing an 
> upsert, dont use MSLAB.  Also based on the Cell size, we sometimes avoid 
> MSLAB copy.  But now we track these cell data size also under the global 
> memstore data size which indicated off heap size in case of off heap 
> memstore.  For global checks for flushes (against lower/upper watermark 
> levels), we check this size against max off heap memstore size.  We do check 
> heap overhead against global heap memstore size (Defaults to 40% of xmx)  But 
> for such cells the data size also should be accounted under the heap overhead.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17647) OffheapKeyValue#heapSize() implementation is wrong

2017-02-22 Thread Anoop Sam John (JIRA)

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

Anoop Sam John updated HBASE-17647:
---
  Resolution: Fixed
Hadoop Flags: Incompatible change,Reviewed
  Status: Resolved  (was: Patch Available)

Thanks for the reviews.  Pushed to master

> OffheapKeyValue#heapSize() implementation is wrong
> --
>
> Key: HBASE-17647
> URL: https://issues.apache.org/jira/browse/HBASE-17647
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-17647.patch, HBASE-17647_V2.patch, 
> HBASE-17647_V3.patch
>
>
> We consider the key and data lengths also even though the data is actually in 
> off heap area.  We should correct it.
> The impact will be at ScannerContext limit tracking where we use heapSize of 
> cells to account the result size.  So my proposal is to consider the cells 
> length and heap size in Limit tracking and accounting.  We have a 
> maxResultSize which defaults to 2MB.  When the sum of all cell's data size 
> reaches 'maxResultSize'  OR the sum of all cell's heap size reaches 
> 'maxResultSize' , we need to send back the RPC response



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Duo Zhang (JIRA)

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

Duo Zhang updated HBASE-17595:
--
Attachment: HBASE-17595-branch-1.patch

Seems the pre commit job has not started. Retry.

> Add partial result support for small/limited scan
> -
>
> Key: HBASE-17595
> URL: https://issues.apache.org/jira/browse/HBASE-17595
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17595-branch-1.patch, HBASE-17595.patch, 
> HBASE-17595-v1.patch
>
>
> The partial result support is marked as a 'TODO' when implementing 
> HBASE-17045. And when implementing HBASE-17508, we found that if we make 
> small scan share the same logic with general scan, the scan request other 
> than open scanner will not have the small flag so the server may return  
> partial result to the client and cause some strange behavior. It is solved by 
> modifying the logic at server side, but this means the 1.4.x client is not 
> safe to contact with earlier 1.x server. So we'd better address the problem 
> at client side. Marked as blocker as this issue should be finished before any 
> 2.x and 1.4.x releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Duo Zhang (JIRA)

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

Duo Zhang updated HBASE-17595:
--
Attachment: (was: HBASE-17595-branch-1.patch)

> Add partial result support for small/limited scan
> -
>
> Key: HBASE-17595
> URL: https://issues.apache.org/jira/browse/HBASE-17595
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17595.patch, HBASE-17595-v1.patch
>
>
> The partial result support is marked as a 'TODO' when implementing 
> HBASE-17045. And when implementing HBASE-17508, we found that if we make 
> small scan share the same logic with general scan, the scan request other 
> than open scanner will not have the small flag so the server may return  
> partial result to the client and cause some strange behavior. It is solved by 
> modifying the logic at server side, but this means the 1.4.x client is not 
> safe to contact with earlier 1.x server. So we'd better address the problem 
> at client side. Marked as blocker as this issue should be finished before any 
> 2.x and 1.4.x releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17662) Disable in-memory flush when replaying from WAL

2017-02-22 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan commented on HBASE-17662:


The changes looks good to me. did you check for [~anoop.hbase]'s suggestion 
that if AtomicBoolean is a must here? Once you feel you have checked it then we 
can get this in.
[~saint@gmail.com]
What ever Anoop says. They are just avoiding in memory flushes not the flush to 
disk. The only thing could be that in case we have lot of duplicates in the 
actual write path and this in memory flush had avoided those duplicates but the 
server crashed on replay we may get lot of duplicates for those WAL entries. I 
think it is not going to affect the data that can be seen but just that they 
will be removed on a compaction only.

> Disable in-memory flush when replaying from WAL
> ---
>
> Key: HBASE-17662
> URL: https://issues.apache.org/jira/browse/HBASE-17662
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
> Attachments: HBASE-17662-V02.patch, HBASE-17662-V03.patch, 
> HBASE-17662-V04.patch
>
>
> When replaying the edits from WAL, the region's updateLock is not taken, 
> because a single threaded action is assumed. However, the thread-safeness of 
> the in-memory flush of CompactingMemStore is based on taking the region's 
> updateLock. 
> The in-memory flush can be skipped in the replay time (anyway everything is 
> flushed to disk just after the replay). Therefore it is acceptable to just 
> skip the in-memory flush action while the updates come as part of replay from 
> WAL.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17343) Make Compacting Memstore default in 2.0 with BASIC as the default type

2017-02-22 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan commented on HBASE-17343:


+1 if the PE /YCSB run shows no regression. Test cases passing is a great sign. 
Sorry I missed this yesterday. 

> Make Compacting Memstore default in 2.0 with BASIC as the default type
> --
>
> Key: HBASE-17343
> URL: https://issues.apache.org/jira/browse/HBASE-17343
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Priority: Blocker
> Fix For: 2.0.0
>
>
> FYI [~anastas], [~eshcar] and [~ebortnik].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16902) Remove directory layout/ filesystem references from hbck tool

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li updated HBASE-16902:
-
Description: 
Remove directory layout/ filesystem references from hbck tool. List of files:
{code}
hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/HFileCorruptionChecker.java
hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java
{code}

  was:
Remove directory layout/ filesystem references form hbck tool. List of files:
{code}
hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/HFileCorruptionChecker.java
hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java
{code}


> Remove directory layout/ filesystem references from hbck tool
> -
>
> Key: HBASE-16902
> URL: https://issues.apache.org/jira/browse/HBASE-16902
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Xiang Li
>
> Remove directory layout/ filesystem references from hbck tool. List of files:
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/HFileCorruptionChecker.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16902) Remove directory layout/ filesystem references from hbck tool

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li commented on HBASE-16902:
--

Correct a typo in title and description: form --> from

> Remove directory layout/ filesystem references from hbck tool
> -
>
> Key: HBASE-16902
> URL: https://issues.apache.org/jira/browse/HBASE-16902
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Xiang Li
>
> Remove directory layout/ filesystem references from hbck tool. List of files:
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/HFileCorruptionChecker.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16902) Remove directory layout/ filesystem references from hbck tool

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li updated HBASE-16902:
-
Summary: Remove directory layout/ filesystem references from hbck tool  
(was: Remove directory layout/ filesystem references form hbck tool)

> Remove directory layout/ filesystem references from hbck tool
> -
>
> Key: HBASE-16902
> URL: https://issues.apache.org/jira/browse/HBASE-16902
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Xiang Li
>
> Remove directory layout/ filesystem references form hbck tool. List of files:
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/HFileCorruptionChecker.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16877) Remove directory layout/ filesystem references from Master

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li updated HBASE-16877:
-
Description: 
Remove directory layout/ filesystem references from Master and add required 
APIs to MasterStorage/ RegionStorage

{code}
hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterWalManager.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/RegionPlacementMaintainer.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureEnv.java
{code}

  was:
Remove directory layout/ filesystem references form Master and add required 
APIs to MasterStorage/ RegionStorage

{code}
hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterWalManager.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/RegionPlacementMaintainer.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java
hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureEnv.java
{code}


> Remove directory layout/ filesystem references from Master
> --
>
> Key: HBASE-16877
> URL: https://issues.apache.org/jira/browse/HBASE-16877
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>
> Remove directory layout/ filesystem references from Master and add required 
> APIs to MasterStorage/ RegionStorage
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterWalManager.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/RegionPlacementMaintainer.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureEnv.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16877) Remove directory layout/ filesystem references from Master

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li updated HBASE-16877:
-
Summary: Remove directory layout/ filesystem references from Master  (was: 
Remove directory layout/ filesystem references form Master)

> Remove directory layout/ filesystem references from Master
> --
>
> Key: HBASE-16877
> URL: https://issues.apache.org/jira/browse/HBASE-16877
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>
> Remove directory layout/ filesystem references form Master and add required 
> APIs to MasterStorage/ RegionStorage
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterWalManager.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/RegionPlacementMaintainer.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureEnv.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16877) Remove directory layout/ filesystem references from Master

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li commented on HBASE-16877:
--

Correct a typo in title and description: form --> from

> Remove directory layout/ filesystem references from Master
> --
>
> Key: HBASE-16877
> URL: https://issues.apache.org/jira/browse/HBASE-16877
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>
> Remove directory layout/ filesystem references from Master and add required 
> APIs to MasterStorage/ RegionStorage
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterWalManager.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/RegionPlacementMaintainer.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/SplitLogManager.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureEnv.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16862) Remove directory layout/ filesystem references from the code in master/procedure directory

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li updated HBASE-16862:
-
Description: Remove directory layout/ filesystem references from the code 
in master/procedure directory.  (was: Remove directory layout/ filesystem 
references form the code in master/procedure directory.)

> Remove directory layout/ filesystem references from the code in 
> master/procedure directory
> --
>
> Key: HBASE-16862
> URL: https://issues.apache.org/jira/browse/HBASE-16862
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: hbase-14439
>
> Attachments: HBASE-16862-hbase-14439.v1.patch, 
> HBASE-16862-hbase-14439.v2.patch
>
>
> Remove directory layout/ filesystem references from the code in 
> master/procedure directory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-17595:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 16s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 8 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 39s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 57s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 47s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 58s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 58s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
25s {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} hadoopcheck {color} | {color:green} 
30m 7s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 0s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 29s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 107m 0s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
32s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 159m 0s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | 
org.apache.hadoop.hbase.coprocessor.TestRegionObserverScannerOpenHook |
|   | org.apache.hadoop.hbase.coprocessor.TestCoprocessorMetrics |
|   | org.apache.hadoop.hbase.snapshot.TestMobRestoreFlushSnapshotFromClient |
|   | org.apache.hadoop.hbase.TestIOFencing |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12854120/HBASE-17595-v1.patch |
| JIRA Issue | HBASE-17595 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 51fa5acedc7e 3.13.0-105-generic #152-Ubuntu SMP Fri Dec 2 
15:37:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 0285cb8 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit | 

[jira] [Commented] (HBASE-16862) Remove directory layout/ filesystem references from the code in master/procedure directory

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li commented on HBASE-16862:
--

Correct a typo in title and description: form --> from. 

> Remove directory layout/ filesystem references from the code in 
> master/procedure directory
> --
>
> Key: HBASE-16862
> URL: https://issues.apache.org/jira/browse/HBASE-16862
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: hbase-14439
>
> Attachments: HBASE-16862-hbase-14439.v1.patch, 
> HBASE-16862-hbase-14439.v2.patch
>
>
> Remove directory layout/ filesystem references from the code in 
> master/procedure directory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16862) Remove directory layout/ filesystem references from the code in master/procedure directory

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li updated HBASE-16862:
-
Summary: Remove directory layout/ filesystem references from the code in 
master/procedure directory  (was: Remove directory layout/ filesystem 
references form the code in master/procedure directory)

> Remove directory layout/ filesystem references from the code in 
> master/procedure directory
> --
>
> Key: HBASE-16862
> URL: https://issues.apache.org/jira/browse/HBASE-16862
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: hbase-14439
>
> Attachments: HBASE-16862-hbase-14439.v1.patch, 
> HBASE-16862-hbase-14439.v2.patch
>
>
> Remove directory layout/ filesystem references form the code in 
> master/procedure directory.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17428) Expand on shell commands for detailed insight

2017-02-22 Thread Josh Elser (JIRA)

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

Josh Elser commented on HBASE-17428:


https://reviews.apache.org/r/56966/

> Expand on shell commands for detailed insight
> -
>
> Key: HBASE-17428
> URL: https://issues.apache.org/jira/browse/HBASE-17428
> Project: HBase
>  Issue Type: Sub-task
>  Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: HBASE-16961
>
> Attachments: HBASE-17428.001.patch, HBASE-17428.002.patch, 
> HBASE-17428.003.HBASE-16961.patch
>
>
> Was talking over how to build some tests with [~romil.choksi], and what kind 
> of information we capture and expose via some more shell commands.
> * Current SpaceQuotaSnapshots that the Master sees
> * Current SpaceQuotaSnapshots that a RS sees (or all RSs)
> * Current SpaceViolationPolicyEnforcements that a RS has enabled
> We can build out on the {{status}} command, with some options for different 
> levels of detail, perhaps. Shouldn't be too tricky -- we have the info, just 
> need to wire up java API, RPC, and shell command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17428) Expand on shell commands for detailed insight

2017-02-22 Thread Josh Elser (JIRA)

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

Josh Elser commented on HBASE-17428:


{quote}
The patch is sizable.

Can you put it on review board ?
{quote}

Sure, not a problem. Lots of generated code, so I didn't initially think to do 
that :)

> Expand on shell commands for detailed insight
> -
>
> Key: HBASE-17428
> URL: https://issues.apache.org/jira/browse/HBASE-17428
> Project: HBase
>  Issue Type: Sub-task
>  Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: HBASE-16961
>
> Attachments: HBASE-17428.001.patch, HBASE-17428.002.patch, 
> HBASE-17428.003.HBASE-16961.patch
>
>
> Was talking over how to build some tests with [~romil.choksi], and what kind 
> of information we capture and expose via some more shell commands.
> * Current SpaceQuotaSnapshots that the Master sees
> * Current SpaceQuotaSnapshots that a RS sees (or all RSs)
> * Current SpaceViolationPolicyEnforcements that a RS has enabled
> We can build out on the {{status}} command, with some options for different 
> levels of detail, perhaps. Shouldn't be too tricky -- we have the info, just 
> need to wire up java API, RPC, and shell command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu updated HBASE-17672:
---
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Thanks for the patch

> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16188) Add EventCounter information to log4j properties file

2017-02-22 Thread Gopi Krishnan Nambiar (JIRA)

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

Gopi Krishnan Nambiar commented on HBASE-16188:
---

[~larsgeorge] could you please have a look at this patch? The test failures are 
unrelated to my changes

> Add EventCounter information to log4j properties file
> -
>
> Key: HBASE-16188
> URL: https://issues.apache.org/jira/browse/HBASE-16188
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Lars George
>Assignee: Gopi Krishnan Nambiar
>Priority: Minor
>  Labels: beginner
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-16188-branch-1.3.patch, HBASE-16188.master.patch
>
>
> Hadoop's {{JvmMetrics}}, which HBase also is using in Metrics2 and provides 
> it as an MBean, has the ability to count log4j log calls. This is tracked by 
> a special {{Appender}} class, also provided by Hadoop, called 
> {{EventCounter}}. 
> We should add some info how to enable this (or maybe even enable it by 
> default?).
> The appender needs to be added in two places, shown here:
> {noformat}
> hbase.root.logger=INFO,console
> ...
> # Define the root logger to the system property "hbase.root.logger".
> log4j.rootLogger=${hbase.root.logger}, EventCounter
> log4j.appender.EventCounter=org.apache.hadoop.log.metrics.EventCounter
> {noformat}
> We could simply add this commented out akin to the {{hbase-env.sh}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17590) Drop cache hint should work for StoreFile write path

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17590:


SUCCESS: Integrated in Jenkins build HBase-1.3-JDK7 #111 (See 
[https://builds.apache.org/job/HBase-1.3-JDK7/111/])
HBASE-17590 Drop cache hint should work on store file write path (Ashu (garyh: 
rev e5dfbe64f45cc931059e8a1d814d8b72d1dbf791)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java


> Drop cache hint should work for StoreFile write path
> 
>
> Key: HBASE-17590
> URL: https://issues.apache.org/jira/browse/HBASE-17590
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Ashu Pachauri
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17590.master.001.patch
>
>
> We have this in the code right now.
> {noformat}
> public Builder withShouldDropCacheBehind(boolean 
> shouldDropCacheBehind/*NOT USED!!*/) {
>   // TODO: HAS NO EFFECT!!! FIX!!
>   return this;
> }
> {noformat}
> Creating jira to track it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16188) Add EventCounter information to log4j properties file

2017-02-22 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-16188:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 15s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 9 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
6s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m 
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 23s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m 
36s {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} hadoopcheck {color} | {color:green} 
29m 16s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m 2s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 56s 
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 47s 
{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 18s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 22s 
{color} | {color:green} hbase-prefix-tree in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 115m 30s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 5m 27s {color} 
| {color:red} hbase-shell in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 29s 
{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 43s 
{color} | {color:green} hbase-rest in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 11s 
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 36s 
{color} | {color:green} hbase-client-project in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 38s 
{color} | {color:green} hbase-shaded-client-project in the patch passed. 
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 119m 22s 
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 2m 
31s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 315m 9s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestShell |
|   | hadoop.hbase.client.TestShell |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12854078/HBASE-16188.master.patch
 |
| JIRA Issue | HBASE-16188 |
| Optional Tests |  asflicense  javac  javadoc  unit  |
| uname | Linux 3650912dbff9 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision 

[jira] [Commented] (HBASE-13882) Fix RegionSplitPolicy section in HBase book

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-13882:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2554 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2554/])
HBASE-13882 Removed part of the RegionSplitPolicy section in HBase book (stack: 
rev 0285cb8c4d358713b096b6c76e07a47d20874277)
* (edit) src/main/asciidoc/_chapters/architecture.adoc


> Fix RegionSplitPolicy section in HBase book 
> 
>
> Key: HBASE-13882
> URL: https://issues.apache.org/jira/browse/HBASE-13882
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Vladimir Rodionov
>Assignee: Jan Hentschel
>Priority: Trivial
> Fix For: 2.0.0
>
> Attachments: HBASE-13882.master.001.patch
>
>
> 65.4.1. Custom Split Policies
> The section starts with the following statement:
> {quote}
> ou can override the default split policy using a custom 
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend 
> HBase’s default split policy: IncreasingToUpperBoundRegionSplitPolicy.
> {quote}
> There is typo above as well.
> Then if we scroll down a little bit:
> {quote}
> The default split policy can be overwritten using a custom 
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend 
> HBase’s default split policy: ConstantSizeRegionSplitPolicy.
> {quote}
> The link:
> http://hbase.apache.org/book.html#_custom_split_policies



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-9702) Change unittests that use "table" or "testtable" to use method names.

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9702:
---

FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2554 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2554/])
HBASE-9702 Changed unit tests to use method names for tables (stack: rev 
c7e605445a495d212136b85db37828b560adf435)
* (edit) 
hbase-thrift/src/test/java/org/apache/hadoop/hbase/thrift2/TestThriftHBaseServiceHandler.java


> Change unittests that use "table" or "testtable" to use method names.
> -
>
> Key: HBASE-9702
> URL: https://issues.apache.org/jira/browse/HBASE-9702
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Reporter: Jonathan Hsieh
>Assignee: Jan Hentschel
> Fix For: 2.0.0
>
> Attachments: HBASE-9702.master.001.patch, HBASE-9702.master.002.patch
>
>
> While working on HBASE-9686, many tests left files that indicated the method 
> they had come from but several drop data in "table" or "testtable" tables.  
> Naming them this way makes it hard to track which tests these came from.  We 
> should make all test use 
> @Rule TestName name = new TestName();
> ...
> TableName  t = TableName.valueOf(name.getMethodName());



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Sean Busbey (JIRA)

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

Sean Busbey updated HBASE-17677:

   Resolution: Fixed
Fix Version/s: 1.1.10
   1.2.5
   1.3.1
   1.4.0
   Status: Resolved  (was: Patch Available)

Thanks for the quick review [~saint@gmail.com].

FYI, I pushed just the tests back to branch-1.1+, so setting fix versions 
appropriately.

> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5, 1.1.10
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2

2017-02-22 Thread Vladimir Rodionov (JIRA)

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

Vladimir Rodionov commented on HBASE-14123:
---

Sure. We have a separate JIRA for documentation - configuration is going to be 
one of a sections.

> HBase Backup/Restore Phase 2
> 
>
> Key: HBASE-14123
> URL: https://issues.apache.org/jira/browse/HBASE-14123
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Fix For: HBASE-7912
>
> Attachments: 14123-master.v14.txt, 14123-master.v15.txt, 
> 14123-master.v16.txt, 14123-master.v17.txt, 14123-master.v18.txt, 
> 14123-master.v19.txt, 14123-master.v20.txt, 14123-master.v21.txt, 
> 14123-master.v24.txt, 14123-master.v25.txt, 14123-master.v27.txt, 
> 14123-master.v28.txt, 14123-master.v29.full.txt, 14123-master.v2.txt, 
> 14123-master.v30.txt, 14123-master.v31.txt, 14123-master.v32.txt, 
> 14123-master.v33.txt, 14123-master.v34.txt, 14123-master.v35.txt, 
> 14123-master.v36.txt, 14123-master.v37.txt, 14123-master.v38.txt, 
> 14123.master.v39.patch, 14123-master.v3.txt, 14123.master.v40.patch, 
> 14123.master.v41.patch, 14123.master.v42.patch, 14123.master.v44.patch, 
> 14123.master.v45.patch, 14123.master.v46.patch, 14123.master.v48.patch, 
> 14123.master.v49.patch, 14123.master.v50.patch, 14123.master.v51.patch, 
> 14123.master.v52.patch, 14123.master.v54.patch, 14123.master.v56.patch, 
> 14123.master.v57.patch, 14123-master.v5.txt, 14123-master.v6.txt, 
> 14123-master.v7.txt, 14123-master.v8.txt, 14123-master.v9.txt, 14123-v14.txt, 
> Backup-restoreinHBase2.0 (1).pdf, Backup-restoreinHBase2.0.pdf, 
> HBASE-14123-for-7912-v1.patch, HBASE-14123-for-7912-v6.patch, 
> HBASE-14123-v10.patch, HBASE-14123-v11.patch, HBASE-14123-v12.patch, 
> HBASE-14123-v13.patch, HBASE-14123-v15.patch, HBASE-14123-v16.patch, 
> HBASE-14123-v1.patch, HBASE-14123-v2.patch, HBASE-14123-v3.patch, 
> HBASE-14123-v4.patch, HBASE-14123-v5.patch, HBASE-14123-v6.patch, 
> HBASE-14123-v7.patch, HBASE-14123-v9.patch
>
>
> Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16902) Remove directory layout/ filesystem references form hbck tool

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li commented on HBASE-16902:
--

Hi [~uagashe], I would like to contribute my time on this JIRA. If I get it 
correctly, hbck tool is relatively independent from other components and 
relatively easier than others. Please let me know your thoughts. 

> Remove directory layout/ filesystem references form hbck tool
> -
>
> Key: HBASE-16902
> URL: https://issues.apache.org/jira/browse/HBASE-16902
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Xiang Li
>
> Remove directory layout/ filesystem references form hbck tool. List of files:
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/HFileCorruptionChecker.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Duo Zhang (JIRA)

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

Duo Zhang updated HBASE-17595:
--
Attachment: HBASE-17595-branch-1.patch

Patch for branch-1.

> Add partial result support for small/limited scan
> -
>
> Key: HBASE-17595
> URL: https://issues.apache.org/jira/browse/HBASE-17595
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17595-branch-1.patch, HBASE-17595.patch, 
> HBASE-17595-v1.patch
>
>
> The partial result support is marked as a 'TODO' when implementing 
> HBASE-17045. And when implementing HBASE-17508, we found that if we make 
> small scan share the same logic with general scan, the scan request other 
> than open scanner will not have the small flag so the server may return  
> partial result to the client and cause some strange behavior. It is solved by 
> modifying the logic at server side, but this means the 1.4.x client is not 
> safe to contact with earlier 1.x server. So we'd better address the problem 
> at client side. Marked as blocker as this issue should be finished before any 
> 2.x and 1.4.x releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (HBASE-16902) Remove directory layout/ filesystem references form hbck tool

2017-02-22 Thread Xiang Li (JIRA)

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

Xiang Li reassigned HBASE-16902:


Assignee: Xiang Li

> Remove directory layout/ filesystem references form hbck tool
> -
>
> Key: HBASE-16902
> URL: https://issues.apache.org/jira/browse/HBASE-16902
> Project: HBase
>  Issue Type: Sub-task
>  Components: Filesystem Integration
>Reporter: Umesh Agashe
>Assignee: Xiang Li
>
> Remove directory layout/ filesystem references form hbck tool. List of files:
> {code}
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/HFileCorruptionChecker.java
> hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/OfflineMetaRepair.java
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (HBASE-17679) Log arguments passed to hbck

2017-02-22 Thread Esteban Gutierrez (JIRA)

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

Esteban Gutierrez resolved HBASE-17679.
---
Resolution: Duplicate

Duplicate of HBASE-12678. Perhaps PrintingErrorReporter sends to stdout that 
information while our log4j properties make the console write to stderr. 

> Log arguments passed to hbck
> 
>
> Key: HBASE-17679
> URL: https://issues.apache.org/jira/browse/HBASE-17679
> Project: HBase
>  Issue Type: Bug
>Reporter: Esteban Gutierrez
>Assignee: Esteban Gutierrez
>Priority: Trivial
>
> Sometimes hbck arguments get lost and we only end up with the output of hbck. 
> This should log some basic info about our arguments passed to hbck for better 
> supportability. Additional server side logging will be added later on HBase 
> Admin calls in a different JIRA.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16990) Shell tool to dump table and namespace privileges

2017-02-22 Thread Zheng Hu (JIRA)

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

Zheng Hu commented on HBASE-16990:
--

ping [~tedyu], [~Apache9], [~esteban], Any concerns for patch v2 ?  Thanks. 

> Shell tool to dump table and namespace privileges
> -
>
> Key: HBASE-16990
> URL: https://issues.apache.org/jira/browse/HBASE-16990
> Project: HBase
>  Issue Type: New Feature
>  Components: tooling
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Minor
> Attachments: HBASE-16990.v1.patch, HBASE-16990.v2.patch, 
> hbase-site.xml
>
>
> Recently,  we are trying to migrate tables from Cluster-A to Cluster-B,  I 
> found that HBase lack some useful tools :
> 1.  dump table schema,  like mysqldump in mysql
> 2.  dump table privileges,  like pt-show-grants in mysql provided by Percona. 
> I think we can add a dump sub-command looks like (JUST simple demo) : 
> {code}
> $ ./bin/hbase dump  -t test_table  --with-privileges  > ~/test_table.hsh
> $ cat ~/test_table.hsh
> create 'test_table', {NAME=>'f1'} 
> grant 'test_user', 'RW', 'test_table'
> {code}
> Maybe I can contribute ...  :)
> How do you think ?  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-14123:


Vlad:
Can you add the above configs to release notes ?

Thanks

> HBase Backup/Restore Phase 2
> 
>
> Key: HBASE-14123
> URL: https://issues.apache.org/jira/browse/HBASE-14123
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Fix For: HBASE-7912
>
> Attachments: 14123-master.v14.txt, 14123-master.v15.txt, 
> 14123-master.v16.txt, 14123-master.v17.txt, 14123-master.v18.txt, 
> 14123-master.v19.txt, 14123-master.v20.txt, 14123-master.v21.txt, 
> 14123-master.v24.txt, 14123-master.v25.txt, 14123-master.v27.txt, 
> 14123-master.v28.txt, 14123-master.v29.full.txt, 14123-master.v2.txt, 
> 14123-master.v30.txt, 14123-master.v31.txt, 14123-master.v32.txt, 
> 14123-master.v33.txt, 14123-master.v34.txt, 14123-master.v35.txt, 
> 14123-master.v36.txt, 14123-master.v37.txt, 14123-master.v38.txt, 
> 14123.master.v39.patch, 14123-master.v3.txt, 14123.master.v40.patch, 
> 14123.master.v41.patch, 14123.master.v42.patch, 14123.master.v44.patch, 
> 14123.master.v45.patch, 14123.master.v46.patch, 14123.master.v48.patch, 
> 14123.master.v49.patch, 14123.master.v50.patch, 14123.master.v51.patch, 
> 14123.master.v52.patch, 14123.master.v54.patch, 14123.master.v56.patch, 
> 14123.master.v57.patch, 14123-master.v5.txt, 14123-master.v6.txt, 
> 14123-master.v7.txt, 14123-master.v8.txt, 14123-master.v9.txt, 14123-v14.txt, 
> Backup-restoreinHBase2.0 (1).pdf, Backup-restoreinHBase2.0.pdf, 
> HBASE-14123-for-7912-v1.patch, HBASE-14123-for-7912-v6.patch, 
> HBASE-14123-v10.patch, HBASE-14123-v11.patch, HBASE-14123-v12.patch, 
> HBASE-14123-v13.patch, HBASE-14123-v15.patch, HBASE-14123-v16.patch, 
> HBASE-14123-v1.patch, HBASE-14123-v2.patch, HBASE-14123-v3.patch, 
> HBASE-14123-v4.patch, HBASE-14123-v5.patch, HBASE-14123-v6.patch, 
> HBASE-14123-v7.patch, HBASE-14123-v9.patch
>
>
> Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17662) Disable in-memory flush when replaying from WAL

2017-02-22 Thread Anoop Sam John (JIRA)

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

Anoop Sam John commented on HBASE-17662:


I dont think she is saying to skip the flush as such.. Ya when the size is more 
than memstore size, we will need a flush (FLush to disk)..  Here she mean abt 
the in memory flush (This happens when memstore size reaches 25% of the region 
flush size - Default).  Make sense boss?

> Disable in-memory flush when replaying from WAL
> ---
>
> Key: HBASE-17662
> URL: https://issues.apache.org/jira/browse/HBASE-17662
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
> Attachments: HBASE-17662-V02.patch, HBASE-17662-V03.patch, 
> HBASE-17662-V04.patch
>
>
> When replaying the edits from WAL, the region's updateLock is not taken, 
> because a single threaded action is assumed. However, the thread-safeness of 
> the in-memory flush of CompactingMemStore is based on taking the region's 
> updateLock. 
> The in-memory flush can be skipped in the replay time (anyway everything is 
> flushed to disk just after the replay). Therefore it is acceptable to just 
> skip the in-memory flush action while the updates come as part of replay from 
> WAL.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17590) Drop cache hint should work for StoreFile write path

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17590:


SUCCESS: Integrated in Jenkins build HBase-1.4 #641 (See 
[https://builds.apache.org/job/HBase-1.4/641/])
HBASE-17590 Drop cache hint should work on store file write path (Ashu (garyh: 
rev a373445730c998d03de7a4ff57a755cbeee31508)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java


> Drop cache hint should work for StoreFile write path
> 
>
> Key: HBASE-17590
> URL: https://issues.apache.org/jira/browse/HBASE-17590
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Ashu Pachauri
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17590.master.001.patch
>
>
> We have this in the code right now.
> {noformat}
> public Builder withShouldDropCacheBehind(boolean 
> shouldDropCacheBehind/*NOT USED!!*/) {
>   // TODO: HAS NO EFFECT!!! FIX!!
>   return this;
> }
> {noformat}
> Creating jira to track it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors

2017-02-22 Thread Zach York (JIRA)

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

Zach York commented on HBASE-17312:
---

[~appy] I had some comments, mostly minor. Thanks!

> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
>  Labels: incompatible
> Attachments: HBASE-17312.master.001.patch, 
> HBASE-17312.master.001.patch, HBASE-17312.master.002.patch
>
>
> In cases where one might need to use multiple observers, say region, master 
> and regionserver; and the fact that only one class can be extended, it gives 
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
>   extends BaseRegionObserver
>   implements MasterObserver
> class AccessController
>   extends BaseMasterAndRegionObserver
>   implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
>  There is an example of simple case too where the current design fails.
>  Say only one observer is needed by the coprocessor, but the design doesn't 
> permit extending even that single observer (see RSGroupAdminEndpoint), that 
> leads to full copy of Base...Observer class into coprocessor class leading to 
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless 
> functions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16990) Shell tool to dump table and namespace privileges

2017-02-22 Thread Zheng Hu (JIRA)

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

Zheng Hu commented on HBASE-16990:
--

[~jerryhe],  Thanks for reply.  permission_dumper.rb is a wrapper for 
user_permission.  For developer,  the script seems  to be redundant. But for 
HBase administrators ,   it's helpful to migrate privileges from one cluster to 
another cluster.   

Currently ,  user_permission shell command print following message: 
{code}
hbase(main):005:0> user_permission 't1'
User 
Namespace,Table,Family,Qualifier:Permission 

  
 openinx default,t1,,: 
[Permission: actions=READ,WRITE,EXEC,CREATE,ADMIN]
...
{code}

If lots of permissions,  then administrator has to spell it in sink hbase shell 
for each permission.  It's time wasting. 


> Shell tool to dump table and namespace privileges
> -
>
> Key: HBASE-16990
> URL: https://issues.apache.org/jira/browse/HBASE-16990
> Project: HBase
>  Issue Type: New Feature
>  Components: tooling
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Minor
> Attachments: HBASE-16990.v1.patch, HBASE-16990.v2.patch, 
> hbase-site.xml
>
>
> Recently,  we are trying to migrate tables from Cluster-A to Cluster-B,  I 
> found that HBase lack some useful tools :
> 1.  dump table schema,  like mysqldump in mysql
> 2.  dump table privileges,  like pt-show-grants in mysql provided by Percona. 
> I think we can add a dump sub-command looks like (JUST simple demo) : 
> {code}
> $ ./bin/hbase dump  -t test_table  --with-privileges  > ~/test_table.hsh
> $ cat ~/test_table.hsh
> create 'test_table', {NAME=>'f1'} 
> grant 'test_user', 'RW', 'test_table'
> {code}
> Maybe I can contribute ...  :)
> How do you think ?  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17590) Drop cache hint should work for StoreFile write path

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17590:


FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #121 (See 
[https://builds.apache.org/job/HBase-1.3-JDK8/121/])
HBASE-17590 Drop cache hint should work on store file write path (Ashu (garyh: 
rev e5dfbe64f45cc931059e8a1d814d8b72d1dbf791)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java


> Drop cache hint should work for StoreFile write path
> 
>
> Key: HBASE-17590
> URL: https://issues.apache.org/jira/browse/HBASE-17590
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Ashu Pachauri
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17590.master.001.patch
>
>
> We have this in the code right now.
> {noformat}
> public Builder withShouldDropCacheBehind(boolean 
> shouldDropCacheBehind/*NOT USED!!*/) {
>   // TODO: HAS NO EFFECT!!! FIX!!
>   return this;
> }
> {noformat}
> Creating jira to track it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Duo Zhang (JIRA)

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

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

Remove testSmallScansDoNotAllowPartials as it is not needed anymore.

Will prepare patch for branch-1.

> Add partial result support for small/limited scan
> -
>
> Key: HBASE-17595
> URL: https://issues.apache.org/jira/browse/HBASE-17595
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17595.patch, HBASE-17595-v1.patch
>
>
> The partial result support is marked as a 'TODO' when implementing 
> HBASE-17045. And when implementing HBASE-17508, we found that if we make 
> small scan share the same logic with general scan, the scan request other 
> than open scanner will not have the small flag so the server may return  
> partial result to the client and cause some strange behavior. It is solved by 
> modifying the logic at server side, but this means the 1.4.x client is not 
> safe to contact with earlier 1.x server. So we'd better address the problem 
> at client side. Marked as blocker as this issue should be finished before any 
> 2.x and 1.4.x releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-17672:


+1 on v2.

> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-17672:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 11s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} rubocop {color} | {color:blue} 0m 5s 
{color} | {color:blue} rubocop was not available. {color} |
| {color:blue}0{color} | {color:blue} ruby-lint {color} | {color:blue} 0m 5s 
{color} | {color:blue} Ruby-lint was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
56s {color} | {color:green} master 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} hadoopcheck {color} | {color:green} 
24m 59s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 50s 
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
8s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 33m 15s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12854110/HBASE-17672.v2.patch |
| JIRA Issue | HBASE-17672 |
| Optional Tests |  asflicense  unit  rubocop  ruby_lint  |
| uname | Linux c9ed95ef7526 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 0285cb8 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5807/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5807/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (HBASE-14123) HBase Backup/Restore Phase 2

2017-02-22 Thread Vladimir Rodionov (JIRA)

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

Vladimir Rodionov edited comment on HBASE-14123 at 2/23/17 1:57 AM:


[~saint@gmail.com], make sure you enable backup fully in hbase-site.xml (on 
all nodes)

{code}
hbase.backup.enable=true
hbase.master.logcleaner.plugins=YOUR_PUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
{code}


was (Author: vrodionov):
[~saint@gmail.com], make sure you enable backup fully in hbase-site.xml

{code}
hbase.backup.enable=true
hbase.master.logcleaner.plugins=YOUR_PUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
{code}

> HBase Backup/Restore Phase 2
> 
>
> Key: HBASE-14123
> URL: https://issues.apache.org/jira/browse/HBASE-14123
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Fix For: HBASE-7912
>
> Attachments: 14123-master.v14.txt, 14123-master.v15.txt, 
> 14123-master.v16.txt, 14123-master.v17.txt, 14123-master.v18.txt, 
> 14123-master.v19.txt, 14123-master.v20.txt, 14123-master.v21.txt, 
> 14123-master.v24.txt, 14123-master.v25.txt, 14123-master.v27.txt, 
> 14123-master.v28.txt, 14123-master.v29.full.txt, 14123-master.v2.txt, 
> 14123-master.v30.txt, 14123-master.v31.txt, 14123-master.v32.txt, 
> 14123-master.v33.txt, 14123-master.v34.txt, 14123-master.v35.txt, 
> 14123-master.v36.txt, 14123-master.v37.txt, 14123-master.v38.txt, 
> 14123.master.v39.patch, 14123-master.v3.txt, 14123.master.v40.patch, 
> 14123.master.v41.patch, 14123.master.v42.patch, 14123.master.v44.patch, 
> 14123.master.v45.patch, 14123.master.v46.patch, 14123.master.v48.patch, 
> 14123.master.v49.patch, 14123.master.v50.patch, 14123.master.v51.patch, 
> 14123.master.v52.patch, 14123.master.v54.patch, 14123.master.v56.patch, 
> 14123.master.v57.patch, 14123-master.v5.txt, 14123-master.v6.txt, 
> 14123-master.v7.txt, 14123-master.v8.txt, 14123-master.v9.txt, 14123-v14.txt, 
> Backup-restoreinHBase2.0 (1).pdf, Backup-restoreinHBase2.0.pdf, 
> HBASE-14123-for-7912-v1.patch, HBASE-14123-for-7912-v6.patch, 
> HBASE-14123-v10.patch, HBASE-14123-v11.patch, HBASE-14123-v12.patch, 
> HBASE-14123-v13.patch, HBASE-14123-v15.patch, HBASE-14123-v16.patch, 
> HBASE-14123-v1.patch, HBASE-14123-v2.patch, HBASE-14123-v3.patch, 
> HBASE-14123-v4.patch, HBASE-14123-v5.patch, HBASE-14123-v6.patch, 
> HBASE-14123-v7.patch, HBASE-14123-v9.patch
>
>
> Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (HBASE-14123) HBase Backup/Restore Phase 2

2017-02-22 Thread Vladimir Rodionov (JIRA)

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

Vladimir Rodionov edited comment on HBASE-14123 at 2/23/17 1:57 AM:


[~saint@gmail.com], make sure you enable backup fully in hbase-site.xml

{code}
hbase.backup.enable=true
hbase.master.logcleaner.plugins=YOUR_PUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
{code}


was (Author: vrodionov):
[~saint@gmail.com], make sure you enable backup fully in hbase-site.xml

{code}
hbase.backup.enable =true
hbase.master.logcleaner.plugins=YOUR_PUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
{code}

> HBase Backup/Restore Phase 2
> 
>
> Key: HBASE-14123
> URL: https://issues.apache.org/jira/browse/HBASE-14123
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Fix For: HBASE-7912
>
> Attachments: 14123-master.v14.txt, 14123-master.v15.txt, 
> 14123-master.v16.txt, 14123-master.v17.txt, 14123-master.v18.txt, 
> 14123-master.v19.txt, 14123-master.v20.txt, 14123-master.v21.txt, 
> 14123-master.v24.txt, 14123-master.v25.txt, 14123-master.v27.txt, 
> 14123-master.v28.txt, 14123-master.v29.full.txt, 14123-master.v2.txt, 
> 14123-master.v30.txt, 14123-master.v31.txt, 14123-master.v32.txt, 
> 14123-master.v33.txt, 14123-master.v34.txt, 14123-master.v35.txt, 
> 14123-master.v36.txt, 14123-master.v37.txt, 14123-master.v38.txt, 
> 14123.master.v39.patch, 14123-master.v3.txt, 14123.master.v40.patch, 
> 14123.master.v41.patch, 14123.master.v42.patch, 14123.master.v44.patch, 
> 14123.master.v45.patch, 14123.master.v46.patch, 14123.master.v48.patch, 
> 14123.master.v49.patch, 14123.master.v50.patch, 14123.master.v51.patch, 
> 14123.master.v52.patch, 14123.master.v54.patch, 14123.master.v56.patch, 
> 14123.master.v57.patch, 14123-master.v5.txt, 14123-master.v6.txt, 
> 14123-master.v7.txt, 14123-master.v8.txt, 14123-master.v9.txt, 14123-v14.txt, 
> Backup-restoreinHBase2.0 (1).pdf, Backup-restoreinHBase2.0.pdf, 
> HBASE-14123-for-7912-v1.patch, HBASE-14123-for-7912-v6.patch, 
> HBASE-14123-v10.patch, HBASE-14123-v11.patch, HBASE-14123-v12.patch, 
> HBASE-14123-v13.patch, HBASE-14123-v15.patch, HBASE-14123-v16.patch, 
> HBASE-14123-v1.patch, HBASE-14123-v2.patch, HBASE-14123-v3.patch, 
> HBASE-14123-v4.patch, HBASE-14123-v5.patch, HBASE-14123-v6.patch, 
> HBASE-14123-v7.patch, HBASE-14123-v9.patch
>
>
> Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2

2017-02-22 Thread Vladimir Rodionov (JIRA)

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

Vladimir Rodionov commented on HBASE-14123:
---

[~saint@gmail.com], make sure you enable backup fully in hbase-site.xml

{code}
hbase.backup.enable =true
hbase.master.logcleaner.plugins=YOUR_PUGINS,org.apache.hadoop.hbase.backup.master.BackupLogCleaner
hbase.procedure.master.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.master.LogRollMasterProcedureManager
hbase.procedure.regionserver.classes=YOUR_CLASSES,org.apache.hadoop.hbase.backup.regionserver.LogRollRegionServerProcedureManager
{code}

> HBase Backup/Restore Phase 2
> 
>
> Key: HBASE-14123
> URL: https://issues.apache.org/jira/browse/HBASE-14123
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Fix For: HBASE-7912
>
> Attachments: 14123-master.v14.txt, 14123-master.v15.txt, 
> 14123-master.v16.txt, 14123-master.v17.txt, 14123-master.v18.txt, 
> 14123-master.v19.txt, 14123-master.v20.txt, 14123-master.v21.txt, 
> 14123-master.v24.txt, 14123-master.v25.txt, 14123-master.v27.txt, 
> 14123-master.v28.txt, 14123-master.v29.full.txt, 14123-master.v2.txt, 
> 14123-master.v30.txt, 14123-master.v31.txt, 14123-master.v32.txt, 
> 14123-master.v33.txt, 14123-master.v34.txt, 14123-master.v35.txt, 
> 14123-master.v36.txt, 14123-master.v37.txt, 14123-master.v38.txt, 
> 14123.master.v39.patch, 14123-master.v3.txt, 14123.master.v40.patch, 
> 14123.master.v41.patch, 14123.master.v42.patch, 14123.master.v44.patch, 
> 14123.master.v45.patch, 14123.master.v46.patch, 14123.master.v48.patch, 
> 14123.master.v49.patch, 14123.master.v50.patch, 14123.master.v51.patch, 
> 14123.master.v52.patch, 14123.master.v54.patch, 14123.master.v56.patch, 
> 14123.master.v57.patch, 14123-master.v5.txt, 14123-master.v6.txt, 
> 14123-master.v7.txt, 14123-master.v8.txt, 14123-master.v9.txt, 14123-v14.txt, 
> Backup-restoreinHBase2.0 (1).pdf, Backup-restoreinHBase2.0.pdf, 
> HBASE-14123-for-7912-v1.patch, HBASE-14123-for-7912-v6.patch, 
> HBASE-14123-v10.patch, HBASE-14123-v11.patch, HBASE-14123-v12.patch, 
> HBASE-14123-v13.patch, HBASE-14123-v15.patch, HBASE-14123-v16.patch, 
> HBASE-14123-v1.patch, HBASE-14123-v2.patch, HBASE-14123-v3.patch, 
> HBASE-14123-v4.patch, HBASE-14123-v5.patch, HBASE-14123-v6.patch, 
> HBASE-14123-v7.patch, HBASE-14123-v9.patch
>
>
> Phase 2 umbrella JIRA. See HBASE-7912 for design document and description. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16942) Add FavoredStochasticLoadBalancer and FN Candidate generators

2017-02-22 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-16942:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 18s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 8 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
19s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 40s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
29m 31s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {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 28s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 118m 12s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
18s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 161m 6s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12854083/HBASE-16942.master.004.patch
 |
| JIRA Issue | HBASE-16942 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 1d437b7877b7 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
 |
| git revision | master / e4c06c1 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5805/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5805/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> Add FavoredStochasticLoadBalancer and FN Candidate generators
> -
>
> Key: HBASE-16942
> URL: https://issues.apache.org/jira/browse/HBASE-16942
> Project: HBase
>  Issue Type: Sub-task
>  Components: FavoredNodes
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
> Fix For: 2.0.0
>
> Attachments: 

[jira] [Commented] (HBASE-17428) Expand on shell commands for detailed insight

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-17428:


The patch is sizable.

Can you put it on review board ?

> Expand on shell commands for detailed insight
> -
>
> Key: HBASE-17428
> URL: https://issues.apache.org/jira/browse/HBASE-17428
> Project: HBase
>  Issue Type: Sub-task
>  Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: HBASE-16961
>
> Attachments: HBASE-17428.001.patch, HBASE-17428.002.patch, 
> HBASE-17428.003.HBASE-16961.patch
>
>
> Was talking over how to build some tests with [~romil.choksi], and what kind 
> of information we capture and expose via some more shell commands.
> * Current SpaceQuotaSnapshots that the Master sees
> * Current SpaceQuotaSnapshots that a RS sees (or all RSs)
> * Current SpaceViolationPolicyEnforcements that a RS has enabled
> We can build out on the {{status}} command, with some options for different 
> levels of detail, perhaps. Shouldn't be too tricky -- we have the info, just 
> need to wire up java API, RPC, and shell command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17595) Add partial result support for small/limited scan

2017-02-22 Thread Duo Zhang (JIRA)

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

Duo Zhang commented on HBASE-17595:
---

Let me check the failed UT.

> Add partial result support for small/limited scan
> -
>
> Key: HBASE-17595
> URL: https://issues.apache.org/jira/browse/HBASE-17595
> Project: HBase
>  Issue Type: Sub-task
>  Components: asyncclient, Client, scan
>Affects Versions: 2.0.0, 1.4.0
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-17595.patch
>
>
> The partial result support is marked as a 'TODO' when implementing 
> HBASE-17045. And when implementing HBASE-17508, we found that if we make 
> small scan share the same logic with general scan, the scan request other 
> than open scanner will not have the small flag so the server may return  
> partial result to the client and cause some strange behavior. It is solved by 
> modifying the logic at server side, but this means the 1.4.x client is not 
> safe to contact with earlier 1.x server. So we'd better address the problem 
> at client side. Marked as blocker as this issue should be finished before any 
> 2.x and 1.4.x releases.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Zheng Hu (JIRA)

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

Zheng Hu commented on HBASE-17672:
--

Any concerns ? [~tedyu] , Thanks. 

> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Zheng Hu (JIRA)

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

Zheng Hu commented on HBASE-17672:
--

> Other than spelling, v2 seems to be same as v1 ? 
Yes.

> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Zheng Hu (JIRA)

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

Zheng Hu commented on HBASE-17672:
--

Upload patch v2 , [~ted_yu]

The original purpose of the UT: 
1.  grant permission like W action. 
2.  assert action exists; 
3.  grant other permissions like RXCA.
4.  assert that whether RXCA will override previous actions.  (after 
HBASE-17472,  assert merge behavior)

The original test use table owner for testing,  so we can skip step.1 because 
RWXCA are granted for owner,  but now we use a new created user 
(test_grant_revoke_user), so we must grant some actions (we choose WRITE) first 
for step.1 .   


> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-17672:


Other than spelling, v2 seems to be same as v1 ?

> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17672) "Grant should set access rights appropriately" test fails

2017-02-22 Thread Zheng Hu (JIRA)

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

Zheng Hu updated HBASE-17672:
-
Attachment: HBASE-17672.v2.patch

> "Grant should set access rights appropriately" test fails
> -
>
> Key: HBASE-17672
> URL: https://issues.apache.org/jira/browse/HBASE-17672
> Project: HBase
>  Issue Type: Test
>Affects Versions: 2.0.0
>Reporter: Ted Yu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17672.patch, HBASE-17672.v1.patch, 
> HBASE-17672.v2.patch
>
>
> The following test failure is reproducible after HBASE-17472 went in:
> {code}
>   1) Failure:
> test_Grant_should_set_access_rights_appropriately(Hbase::SecureAdminMethodsTest)
> [./src/test/ruby/hbase/security_admin_test.rb:66:in 
> `test_Grant_should_set_access_rights_appropriately'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:154:in 
> `user_permission'
>  
> file:/Users/tyu/.m2/repository/org/jruby/jruby-complete/1.6.8/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
>  `each'
>  /Users/tyu/trunk/hbase-shell/src/main/ruby/hbase/security.rb:136:in 
> `user_permission'
>  ./src/test/ruby/hbase/security_admin_test.rb:65:in 
> `test_Grant_should_set_access_rights_appropriately'
>  org/jruby/RubyProc.java:270:in `call'
>  org/jruby/RubyKernel.java:2105:in `send'
>  org/jruby/RubyArray.java:1620:in `each'
>  org/jruby/RubyArray.java:1620:in `each']:
> {code}
> [~openinx]:
> Can you take a look ?



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-14123) HBase Backup/Restore Phase 2

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-14123:
---

Trying the patch:

What is this format when I list out my set named 'me' w/ three tables in it:

me={x,y,z}

Is it json or something else?

I started up a job with following:

./hbase/bin/hbase --config ~/conf_hbase backup create full 
hdfs://ve0524.halxg.cloudera.com:8020/bkup

... it seems to have started. No progress. I killed the command. When I do 
progress, it found a job:

Found ongoing session with backupId=backup_1487810721996
backup_1487810721996 progress=0%

Says... zero progress. I looked for the bkup dir but not created. Its not 
running a mr job that I can tell. I do a describe and it says:

{ID=backup_1487810721996,Type=FULL,Tables={IntegrationTestBigLinkedList,x,y,z},State=RUNNING,Start
 time=Wed Feb 22 16:45:22 PST 2017,Phase=REQUEST,Progress=0%}

(Is the above JSON?)

If I delete the backup, it seems to get rid of it.

Any idea what I did wrong?

The backup create usage mentions 'restore' when it should be 'backup'?

{code}
Usage: hbase backup create   [options]
  type   "full" to create a full backup image
 "incremental" to create an incremental backup image
  backup_path Full path to store the backup image

Options:
  -b Bandwidth per task (MapReduce task) in MB/s
  -s Backup set to restore, mutually exclusive with -t (table list)
  -t Table name list, comma-separated.
  -w Number of parallel MapReduce tasks to execute
{code}

I retried creating a backup with three empty tables in a set It does this:

{code}
stack@ve0524:~$ ./hbase/bin/hbase --config ~/conf_hbase backup create full 
hdfs://ve0524.halxg.cloudera.com:8020/bkup -s me
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/home/stack/hbase-2.0.0-SNAPSHOT/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/home/stack/hadoop-2.7.4-SNAPSHOT/share/hadoop/common/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
2017-02-22 16:59:53,327 DEBUG [main] util.ClassSize: Using Unsafe to estimate 
memory layout
2017-02-22 16:59:53,332 DEBUG [main] ipc.AbstractRpcClient: 
Codec=org.apache.hadoop.hbase.codec.KeyValueCodec@5644dc81, compressor=null, 
tcpKeepAlive=true, tcpNoDelay=true, connectTO=1, readTO=2, 
writeTO=6, minIdleTimeBeforeClose=12, maxRetries=0, 
fallbackAllowed=false, bind address=null
2017-02-22 16:59:53,589 DEBUG [main] ipc.RpcConnection: Use SIMPLE 
authentication for service ClientService, sasl=false
2017-02-22 16:59:53,754 DEBUG [main] ipc.NettyRpcConnection: Connecting to 
ve0542.halxg.cloudera.com/10.17.240.29:16020
2017-02-22 16:59:53,908 DEBUG [main] ipc.RpcConnection: Use SIMPLE 
authentication for service ClientService, sasl=false
2017-02-22 16:59:53,908 DEBUG [main] ipc.NettyRpcConnection: Connecting to 
ve0542.halxg.cloudera.com/10.17.240.29:16020
2017-02-22 16:59:53,911 DEBUG [main] ipc.RpcConnection: Use SIMPLE 
authentication for service ClientService, sasl=false
2017-02-22 16:59:53,912 DEBUG [main] ipc.NettyRpcConnection: Connecting to 
ve0542.halxg.cloudera.com/10.17.240.29:16020
2017-02-22 16:59:53,959 DEBUG [hconnection-0x130e116b-shared-pool3-t1] 
ipc.RpcConnection: Use SIMPLE authentication for service ClientService, 
sasl=false
2017-02-22 16:59:53,959 DEBUG [hconnection-0x130e116b-shared-pool3-t1] 
ipc.NettyRpcConnection: Connecting to 
ve0542.halxg.cloudera.com/10.17.240.29:16020
2017-02-22 16:59:53,992 DEBUG 
[hconnection-0x130e116b-metaLookup-shared--pool5-t1] ipc.RpcConnection: Use 
SIMPLE authentication for service ClientService, sasl=false
2017-02-22 16:59:53,993 DEBUG 
[hconnection-0x130e116b-metaLookup-shared--pool5-t1] ipc.NettyRpcConnection: 
Connecting to ve0542.halxg.cloudera.com/10.17.240.29:16020
2017-02-22 16:59:54,002 DEBUG [main] ipc.RpcConnection: Use SIMPLE 
authentication for service ClientService, sasl=false
2017-02-22 16:59:54,003 DEBUG [main] ipc.NettyRpcConnection: Connecting to 
ve0538.halxg.cloudera.com/10.17.240.27:16020
2017-02-22 16:59:54,029 DEBUG [main] ipc.AbstractRpcClient: Stopping rpc client
2017-02-22 16:59:54,040 DEBUG [main] ipc.AbstractRpcClient: 
Codec=org.apache.hadoop.hbase.codec.KeyValueCodec@2c1dc8e, compressor=null, 
tcpKeepAlive=true, tcpNoDelay=true, connectTO=1, readTO=2, 
writeTO=6, minIdleTimeBeforeClose=12, maxRetries=0, 
fallbackAllowed=false, bind address=null
2017-02-22 16:59:54,171 DEBUG [main] ipc.RpcConnection: Use SIMPLE 
authentication for service ClientService, sasl=false
2017-02-22 16:59:54,171 DEBUG [main] ipc.NettyRpcConnection: Connecting to 

[jira] [Updated] (HBASE-17680) Run mini cluster through JNI in tests

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu updated HBASE-17680:
---
Attachment: 17680.v3.txt

Patch v3 removes commented out code.

TestUtil is moved to test class level since TestUtil ctor starts mini cluster 
which should be reused by all the subtests in the same test class.

> Run mini cluster through JNI in tests
> -
>
> Key: HBASE-17680
> URL: https://issues.apache.org/jira/browse/HBASE-17680
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17680.v1.txt, 17680.v3.txt
>
>
> Currently tests start local hbase cluster through hbase shell.
> There is less control over the configuration of the local cluster this way.
> This issue would replace hbase shell with JNI interface to mini cluster.
> We would have full control over the cluster behavior.
> Thanks to [~devaraj] who started this initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-13882) Fix RegionSplitPolicy section in HBase book

2017-02-22 Thread stack (JIRA)

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

stack updated HBASE-13882:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

Pushed. Thanks [~Jan Hentschel]

> Fix RegionSplitPolicy section in HBase book 
> 
>
> Key: HBASE-13882
> URL: https://issues.apache.org/jira/browse/HBASE-13882
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Vladimir Rodionov
>Assignee: Jan Hentschel
>Priority: Trivial
> Fix For: 2.0.0
>
> Attachments: HBASE-13882.master.001.patch
>
>
> 65.4.1. Custom Split Policies
> The section starts with the following statement:
> {quote}
> ou can override the default split policy using a custom 
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend 
> HBase’s default split policy: IncreasingToUpperBoundRegionSplitPolicy.
> {quote}
> There is typo above as well.
> Then if we scroll down a little bit:
> {quote}
> The default split policy can be overwritten using a custom 
> RegionSplitPolicy(HBase 0.94+). Typically a custom split policy should extend 
> HBase’s default split policy: ConstantSizeRegionSplitPolicy.
> {quote}
> The link:
> http://hbase.apache.org/book.html#_custom_split_policies



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17680) Run mini cluster through JNI in tests

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-17680:


The two tests where shell command is replaced:
{code}
RESULTS FOR //core:location-cache-test
PASS  5.2s  3 Passed   0 Skipped   0 Failed   //core:location-cache-test
TESTS PASSED
RESULTS FOR //core:client-test
PASS  2.8s  6 Passed   0 Skipped   0 Failed   //core:client-test
TESTS PASSED
{code}

> Run mini cluster through JNI in tests
> -
>
> Key: HBASE-17680
> URL: https://issues.apache.org/jira/browse/HBASE-17680
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17680.v1.txt
>
>
> Currently tests start local hbase cluster through hbase shell.
> There is less control over the configuration of the local cluster this way.
> This issue would replace hbase shell with JNI interface to mini cluster.
> We would have full control over the cluster behavior.
> Thanks to [~devaraj] who started this initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17662) Disable in-memory flush when replaying from WAL

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17662:
---

...though taking the lock, would that mean no flush during replay... If so, 
then that wouldn't be correct either.

> Disable in-memory flush when replaying from WAL
> ---
>
> Key: HBASE-17662
> URL: https://issues.apache.org/jira/browse/HBASE-17662
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
> Attachments: HBASE-17662-V02.patch, HBASE-17662-V03.patch, 
> HBASE-17662-V04.patch
>
>
> When replaying the edits from WAL, the region's updateLock is not taken, 
> because a single threaded action is assumed. However, the thread-safeness of 
> the in-memory flush of CompactingMemStore is based on taking the region's 
> updateLock. 
> The in-memory flush can be skipped in the replay time (anyway everything is 
> flushed to disk just after the replay). Therefore it is acceptable to just 
> skip the in-memory flush action while the updates come as part of replay from 
> WAL.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17662) Disable in-memory flush when replaying from WAL

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17662:
---

bq. Therefore it is acceptable to just skip the in-memory flush action while 
the updates come as part of replay from WAL.

IIRC, you would flush during replay when the replayed data was bigger than your 
memory could hold  Turning it off would mess us up. Could you instead take 
the update lock during replay?

> Disable in-memory flush when replaying from WAL
> ---
>
> Key: HBASE-17662
> URL: https://issues.apache.org/jira/browse/HBASE-17662
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Anastasia Braginsky
>Assignee: Anastasia Braginsky
> Attachments: HBASE-17662-V02.patch, HBASE-17662-V03.patch, 
> HBASE-17662-V04.patch
>
>
> When replaying the edits from WAL, the region's updateLock is not taken, 
> because a single threaded action is assumed. However, the thread-safeness of 
> the in-memory flush of CompactingMemStore is based on taking the region's 
> updateLock. 
> The in-memory flush can be skipped in the replay time (anyway everything is 
> flushed to disk just after the replay). Therefore it is acceptable to just 
> skip the in-memory flush action while the updates come as part of replay from 
> WAL.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17343) Make Compacting Memstore default in 2.0 with BASIC as the default type

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17343:
---

Yeah, a YCSB run would do too... as per [~anoop.hbase]. I could do it even. Put 
up a patch.

> Make Compacting Memstore default in 2.0 with BASIC as the default type
> --
>
> Key: HBASE-17343
> URL: https://issues.apache.org/jira/browse/HBASE-17343
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ramkrishna.s.vasudevan
>Priority: Blocker
> Fix For: 2.0.0
>
>
> FYI [~anastas], [~eshcar] and [~ebortnik].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17590) Drop cache hint should work for StoreFile write path

2017-02-22 Thread Hudson (JIRA)

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

Hudson commented on HBASE-17590:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2553 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2553/])
HBASE-17590 Drop cache hint should work on store file write path (Ashu (garyh: 
rev e4c06c120a8bb964fe72412cef216647b147de72)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFileWriter.java


> Drop cache hint should work for StoreFile write path
> 
>
> Key: HBASE-17590
> URL: https://issues.apache.org/jira/browse/HBASE-17590
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Ashu Pachauri
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17590.master.001.patch
>
>
> We have this in the code right now.
> {noformat}
> public Builder withShouldDropCacheBehind(boolean 
> shouldDropCacheBehind/*NOT USED!!*/) {
>   // TODO: HAS NO EFFECT!!! FIX!!
>   return this;
> }
> {noformat}
> Creating jira to track it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17680) Run mini cluster through JNI in tests

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17680:
---

We already write a cache of classpath at ./target/cached_classpath.txt

> Run mini cluster through JNI in tests
> -
>
> Key: HBASE-17680
> URL: https://issues.apache.org/jira/browse/HBASE-17680
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17680.v1.txt
>
>
> Currently tests start local hbase cluster through hbase shell.
> There is less control over the configuration of the local cluster this way.
> This issue would replace hbase shell with JNI interface to mini cluster.
> We would have full control over the cluster behavior.
> Thanks to [~devaraj] who started this initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (HBASE-17681) Simplify ssh and 'Operation Not Permitted' issues when our IT tests execute monkeys

2017-02-22 Thread Appy (JIRA)
Appy created HBASE-17681:


 Summary: Simplify ssh and 'Operation Not Permitted' issues when 
our IT tests execute monkeys
 Key: HBASE-17681
 URL: https://issues.apache.org/jira/browse/HBASE-17681
 Project: HBase
  Issue Type: Improvement
Reporter: Appy
Assignee: Appy


{noformat}
Executing remote command: ps ux | grep proc_regionserver | grep -v grep | tr -s 
' ' | cut -d ' ' -f2 | xargs kill -s SIGKILL , hostname:appy2-5.vpc.cloudera.com
util.Shell: Executing full command [/usr/bin/ssh  appy2-5.vpc.cloudera.com 
"sudo -u hbase ps ux | grep proc_regionserver | grep -v grep | tr -s ' ' | cut 
-d ' ' -f2 | xargs kill -s SIGKILL"]
{noformat}

The issue with above command is:
- kill commands runs as the ssh'ed user, and if it's not hbase, it has to be 
root
- which means, that either hbase or root needs to have passwordless access 
setup to all the other hosts of the cluster, which may not be true in many 
cases.

Generalizing it a bit so that it can also work with a setup when there is a 
user (\*any\* user) in the cluster with passwordless access to other nodes, and 
sudo permissions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (HBASE-17428) Expand on shell commands for detailed insight

2017-02-22 Thread Josh Elser (JIRA)

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

Josh Elser edited comment on HBASE-17428 at 2/22/17 11:14 PM:
--

.003 Has some cleanup over 002 and adds a ruby test.

FYI [~tedyu]


was (Author: elserj):
.003 Has some cleanup over 002 and adds a ruby test.

> Expand on shell commands for detailed insight
> -
>
> Key: HBASE-17428
> URL: https://issues.apache.org/jira/browse/HBASE-17428
> Project: HBase
>  Issue Type: Sub-task
>  Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: HBASE-16961
>
> Attachments: HBASE-17428.001.patch, HBASE-17428.002.patch, 
> HBASE-17428.003.HBASE-16961.patch
>
>
> Was talking over how to build some tests with [~romil.choksi], and what kind 
> of information we capture and expose via some more shell commands.
> * Current SpaceQuotaSnapshots that the Master sees
> * Current SpaceQuotaSnapshots that a RS sees (or all RSs)
> * Current SpaceViolationPolicyEnforcements that a RS has enabled
> We can build out on the {{status}} command, with some options for different 
> levels of detail, perhaps. Shouldn't be too tricky -- we have the info, just 
> need to wire up java API, RPC, and shell command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17428) Expand on shell commands for detailed insight

2017-02-22 Thread Josh Elser (JIRA)

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

Josh Elser updated HBASE-17428:
---
Attachment: HBASE-17428.003.HBASE-16961.patch

.003 Has some cleanup over 002 and adds a ruby test.

> Expand on shell commands for detailed insight
> -
>
> Key: HBASE-17428
> URL: https://issues.apache.org/jira/browse/HBASE-17428
> Project: HBase
>  Issue Type: Sub-task
>  Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: HBASE-16961
>
> Attachments: HBASE-17428.001.patch, HBASE-17428.002.patch, 
> HBASE-17428.003.HBASE-16961.patch
>
>
> Was talking over how to build some tests with [~romil.choksi], and what kind 
> of information we capture and expose via some more shell commands.
> * Current SpaceQuotaSnapshots that the Master sees
> * Current SpaceQuotaSnapshots that a RS sees (or all RSs)
> * Current SpaceViolationPolicyEnforcements that a RS has enabled
> We can build out on the {{status}} command, with some options for different 
> levels of detail, perhaps. Shouldn't be too tricky -- we have the info, just 
> need to wire up java API, RPC, and shell command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17428) Expand on shell commands for detailed insight

2017-02-22 Thread Josh Elser (JIRA)

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

Josh Elser updated HBASE-17428:
---
Fix Version/s: HBASE-16961

> Expand on shell commands for detailed insight
> -
>
> Key: HBASE-17428
> URL: https://issues.apache.org/jira/browse/HBASE-17428
> Project: HBase
>  Issue Type: Sub-task
>  Components: shell
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: HBASE-16961
>
> Attachments: HBASE-17428.001.patch, HBASE-17428.002.patch, 
> HBASE-17428.003.HBASE-16961.patch
>
>
> Was talking over how to build some tests with [~romil.choksi], and what kind 
> of information we capture and expose via some more shell commands.
> * Current SpaceQuotaSnapshots that the Master sees
> * Current SpaceQuotaSnapshots that a RS sees (or all RSs)
> * Current SpaceViolationPolicyEnforcements that a RS has enabled
> We can build out on the {{status}} command, with some options for different 
> levels of detail, perhaps. Shouldn't be too tricky -- we have the info, just 
> need to wire up java API, RPC, and shell command.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17680) Run mini cluster through JNI in tests

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-17680:


docker hardcodes CLASSPATH as 
"/usr/src/buck/build/bootstrapper/bootstrapper.jar"

Workaround is to embed the output of "bin/hbase classpath" command in a file 
(/tmp/clspath) which would be read by MiniCluster#create_vm()

> Run mini cluster through JNI in tests
> -
>
> Key: HBASE-17680
> URL: https://issues.apache.org/jira/browse/HBASE-17680
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17680.v1.txt
>
>
> Currently tests start local hbase cluster through hbase shell.
> There is less control over the configuration of the local cluster this way.
> This issue would replace hbase shell with JNI interface to mini cluster.
> We would have full control over the cluster behavior.
> Thanks to [~devaraj] who started this initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17680) Run mini cluster through JNI in tests

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu updated HBASE-17680:
---
Attachment: 17680.v1.txt

> Run mini cluster through JNI in tests
> -
>
> Key: HBASE-17680
> URL: https://issues.apache.org/jira/browse/HBASE-17680
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 17680.v1.txt
>
>
> Currently tests start local hbase cluster through hbase shell.
> There is less control over the configuration of the local cluster this way.
> This issue would replace hbase shell with JNI interface to mini cluster.
> We would have full control over the cluster behavior.
> Thanks to [~devaraj] who started this initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17069) RegionServer writes invalid META entries for split daughters in some circumstances

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17069:
---

bq. From what i understood we enter the below block only when the walEdit is 
not empty and we have some cells in the wal edit from the processed mutations.

You are right. I was wrong (misreading). It was probably set to 'false' because 
we haven't added the append to memstore yet... that happens next... which seems 
reasonable.

bq.  In SequenceIdAccounting.update() we pass false for the multirequest (lets 
say sequence id here was 1) so lowestunflusedsequenceid is not updated.

The edit is in WAL, perhaps unsynced, but not in memstore (yet); a limbo. 
Another limbo is the gap while we wait for an edit to be stamped with a 
sequenceid (HBASE-17471 and friends help here)

bq. Now for the second put that goes through doMiniBatchMutation we pass true 
correctly during append(Seq id 2). lowestUnflushedSequenceIds is set to 2 for 
the metafamily. 

Issue is we have two ways of writing (smile) and they don't agree which is 
especially fun in times of high concurrency where behind the scenes we are 
trying to keep an incrementing counter that aligns with order in which edits 
arrive.

Setting true as the patch does seems like a low-risk way of keeping stuff 
aligned in branch-1.2/1.3. We should do a follow-on for branch-1 to correct the 
fuzzyness around inmemory flag and ensure that the rare edit that is not meant 
for memstore doesn't cause an issue similar to here because it has us skip out 
on sequenceid accounting.

Thanks [~abhishek.chouhan]

> RegionServer writes invalid META entries for split daughters in some 
> circumstances
> --
>
> Key: HBASE-17069
> URL: https://issues.apache.org/jira/browse/HBASE-17069
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>Reporter: Andrew Purtell
>Assignee: Abhishek Singh Chouhan
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5
>
> Attachments: daughter_1_d55ef81c2f8299abbddfce0445067830.log, 
> daughter_2_08629d59564726da2497f70451aafcdb.log, 
> HBASE-17069.branch-1.3.001.patch, HBASE-17069.branch-1.3.002.patch, 
> HBASE-17069.master.001.patch, logs.tar.gz, 
> parent-393d2bfd8b1c52ce08540306659624f2.log
>
>
> I have been seeing frequent ITBLL failures testing various versions of 1.2.x. 
> Over the lifetime of 1.2.x the following issues have been fixed:
> - HBASE-15315 (Remove always set super user call as high priority)
> - HBASE-16093 (Fix splits failed before creating daughter regions leave meta 
> inconsistent)
> And this one is pending:
> - HBASE-17044 (Fix merge failed before creating merged region leaves meta 
> inconsistent)
> I can apply all of the above to branch-1.2 and still see this failure: 
> *The life of stillborn region d55ef81c2f8299abbddfce0445067830*
> *Master sees SPLITTING_NEW*
> {noformat}
> 2016-11-08 04:23:21,186 INFO  [AM.ZK.Worker-pool2-t82] master.RegionStates: 
> Transition null to {d55ef81c2f8299abbddfce0445067830 state=SPLITTING_NEW, 
> ts=1478579001186, server=node-3.cluster,16020,1478578389506}
> {noformat}
> *The RegionServer creates it*
> {noformat}
> 2016-11-08 04:23:26,035 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for GomnU: blockCache=LruBlockCache{blockCount=34, 
> currentSize=14996112, freeSize=12823716208, maxSize=12838712320, 
> heapSize=14996112, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,038 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for big: blockCache=LruBlockCache{blockCount=34, 
> currentSize=14996112, freeSize=12823716208, maxSize=12838712320, 
> heapSize=14996112, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,442 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for meta: blockCache=LruBlockCache{blockCount=63, 
> currentSize=17187656, freeSize=12821524664, maxSize=12838712320, 
> heapSize=17187656, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> 

[jira] [Updated] (HBASE-17680) Run mini cluster through JNI in tests

2017-02-22 Thread Ted Yu (JIRA)

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

Ted Yu updated HBASE-17680:
---
Description: 
Currently tests start local hbase cluster through hbase shell.
There is less control over the configuration of the local cluster this way.

This issue would replace hbase shell with JNI interface to mini cluster.
We would have full control over the cluster behavior.

Thanks to [~devaraj] who started this initiative.

  was:
Currently tests start local hbase cluster through hbase shell.
There is less control over the configuration of the local cluster this way.

This issue would replace hbase shell with JNI interface to mini cluster.
We would have full control over the cluster behavior.

Thanks to [~ddas] who started this initiative.


> Run mini cluster through JNI in tests
> -
>
> Key: HBASE-17680
> URL: https://issues.apache.org/jira/browse/HBASE-17680
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
>
> Currently tests start local hbase cluster through hbase shell.
> There is less control over the configuration of the local cluster this way.
> This issue would replace hbase shell with JNI interface to mini cluster.
> We would have full control over the cluster behavior.
> Thanks to [~devaraj] who started this initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (HBASE-17680) Run mini cluster through JNI in tests

2017-02-22 Thread Ted Yu (JIRA)
Ted Yu created HBASE-17680:
--

 Summary: Run mini cluster through JNI in tests
 Key: HBASE-17680
 URL: https://issues.apache.org/jira/browse/HBASE-17680
 Project: HBase
  Issue Type: Sub-task
Reporter: Ted Yu
Assignee: Ted Yu


Currently tests start local hbase cluster through hbase shell.
There is less control over the configuration of the local cluster this way.

This issue would replace hbase shell with JNI interface to mini cluster.
We would have full control over the cluster behavior.

Thanks to [~ddas] who started this initiative.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16942) Add FavoredStochasticLoadBalancer and FN Candidate generators

2017-02-22 Thread Thiruvel Thirumoolan (JIRA)

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

Thiruvel Thirumoolan updated HBASE-16942:
-
Summary: Add FavoredStochasticLoadBalancer and FN Candidate generators  
(was: FavoredNodes - Balancer improvements)

> Add FavoredStochasticLoadBalancer and FN Candidate generators
> -
>
> Key: HBASE-16942
> URL: https://issues.apache.org/jira/browse/HBASE-16942
> Project: HBase
>  Issue Type: Sub-task
>  Components: FavoredNodes
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
> Fix For: 2.0.0
>
> Attachments: HBASE-16942.master.001.patch, 
> HBASE-16942.master.002.patch, HBASE-16942.master.003.patch, 
> HBASE-16942.master.004.patch, HBASE_16942_rough_draft.patch
>
>
> This deals with the balancer based enhancements to favored nodes patch as 
> discussed in HBASE-15532.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16942) FavoredNodes - Balancer improvements

2017-02-22 Thread Thiruvel Thirumoolan (JIRA)

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

Thiruvel Thirumoolan updated HBASE-16942:
-
Attachment: HBASE-16942.master.004.patch

> FavoredNodes - Balancer improvements
> 
>
> Key: HBASE-16942
> URL: https://issues.apache.org/jira/browse/HBASE-16942
> Project: HBase
>  Issue Type: Sub-task
>  Components: FavoredNodes
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
> Fix For: 2.0.0
>
> Attachments: HBASE-16942.master.001.patch, 
> HBASE-16942.master.002.patch, HBASE-16942.master.003.patch, 
> HBASE-16942.master.004.patch, HBASE_16942_rough_draft.patch
>
>
> This deals with the balancer based enhancements to favored nodes patch as 
> discussed in HBASE-15532.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17582) Drop page cache hint is broken

2017-02-22 Thread Gary Helmling (JIRA)

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

Gary Helmling commented on HBASE-17582:
---

+1 on the patch.

> Drop page cache hint is broken
> --
>
> Key: HBASE-17582
> URL: https://issues.apache.org/jira/browse/HBASE-17582
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction, io
>Affects Versions: 2.0.0
>Reporter: Ashu Pachauri
>Assignee: Appy
>Priority: Critical
> Attachments: HBASE-17582.master.001.patch
>
>
> We pass a boolean for pass page cache drop hint while creating store file 
> scanners and writers. 
> The hint is not passed on down the stack by StoreFileWriter and 
> StoreFileScanner in the master branch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16188) Add EventCounter information to log4j properties file

2017-02-22 Thread Gopi Krishnan Nambiar (JIRA)

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

Gopi Krishnan Nambiar updated HBASE-16188:
--
Attachment: (was: HBASE-16188.patch)

> Add EventCounter information to log4j properties file
> -
>
> Key: HBASE-16188
> URL: https://issues.apache.org/jira/browse/HBASE-16188
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Lars George
>Assignee: Gopi Krishnan Nambiar
>Priority: Minor
>  Labels: beginner
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-16188-branch-1.3.patch, HBASE-16188.master.patch
>
>
> Hadoop's {{JvmMetrics}}, which HBase also is using in Metrics2 and provides 
> it as an MBean, has the ability to count log4j log calls. This is tracked by 
> a special {{Appender}} class, also provided by Hadoop, called 
> {{EventCounter}}. 
> We should add some info how to enable this (or maybe even enable it by 
> default?).
> The appender needs to be added in two places, shown here:
> {noformat}
> hbase.root.logger=INFO,console
> ...
> # Define the root logger to the system property "hbase.root.logger".
> log4j.rootLogger=${hbase.root.logger}, EventCounter
> log4j.appender.EventCounter=org.apache.hadoop.log.metrics.EventCounter
> {noformat}
> We could simply add this commented out akin to the {{hbase-env.sh}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16188) Add EventCounter information to log4j properties file

2017-02-22 Thread Gopi Krishnan Nambiar (JIRA)

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

Gopi Krishnan Nambiar updated HBASE-16188:
--
Attachment: HBASE-16188.master.patch
HBASE-16188-branch-1.3.patch

> Add EventCounter information to log4j properties file
> -
>
> Key: HBASE-16188
> URL: https://issues.apache.org/jira/browse/HBASE-16188
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Lars George
>Assignee: Gopi Krishnan Nambiar
>Priority: Minor
>  Labels: beginner
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-16188-branch-1.3.patch, HBASE-16188.master.patch
>
>
> Hadoop's {{JvmMetrics}}, which HBase also is using in Metrics2 and provides 
> it as an MBean, has the ability to count log4j log calls. This is tracked by 
> a special {{Appender}} class, also provided by Hadoop, called 
> {{EventCounter}}. 
> We should add some info how to enable this (or maybe even enable it by 
> default?).
> The appender needs to be added in two places, shown here:
> {noformat}
> hbase.root.logger=INFO,console
> ...
> # Define the root logger to the system property "hbase.root.logger".
> log4j.rootLogger=${hbase.root.logger}, EventCounter
> log4j.appender.EventCounter=org.apache.hadoop.log.metrics.EventCounter
> {noformat}
> We could simply add this commented out akin to the {{hbase-env.sh}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Work started] (HBASE-16188) Add EventCounter information to log4j properties file

2017-02-22 Thread Gopi Krishnan Nambiar (JIRA)

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

Work on HBASE-16188 started by Gopi Krishnan Nambiar.
-
> Add EventCounter information to log4j properties file
> -
>
> Key: HBASE-16188
> URL: https://issues.apache.org/jira/browse/HBASE-16188
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Lars George
>Assignee: Gopi Krishnan Nambiar
>Priority: Minor
>  Labels: beginner
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-16188-branch-1.3.patch, HBASE-16188.master.patch
>
>
> Hadoop's {{JvmMetrics}}, which HBase also is using in Metrics2 and provides 
> it as an MBean, has the ability to count log4j log calls. This is tracked by 
> a special {{Appender}} class, also provided by Hadoop, called 
> {{EventCounter}}. 
> We should add some info how to enable this (or maybe even enable it by 
> default?).
> The appender needs to be added in two places, shown here:
> {noformat}
> hbase.root.logger=INFO,console
> ...
> # Define the root logger to the system property "hbase.root.logger".
> log4j.rootLogger=${hbase.root.logger}, EventCounter
> log4j.appender.EventCounter=org.apache.hadoop.log.metrics.EventCounter
> {noformat}
> We could simply add this commented out akin to the {{hbase-env.sh}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16188) Add EventCounter information to log4j properties file

2017-02-22 Thread Gopi Krishnan Nambiar (JIRA)

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

Gopi Krishnan Nambiar updated HBASE-16188:
--
Fix Version/s: 1.3.0
   Status: Patch Available  (was: In Progress)

> Add EventCounter information to log4j properties file
> -
>
> Key: HBASE-16188
> URL: https://issues.apache.org/jira/browse/HBASE-16188
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Lars George
>Assignee: Gopi Krishnan Nambiar
>Priority: Minor
>  Labels: beginner
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-16188-branch-1.3.patch, HBASE-16188.master.patch
>
>
> Hadoop's {{JvmMetrics}}, which HBase also is using in Metrics2 and provides 
> it as an MBean, has the ability to count log4j log calls. This is tracked by 
> a special {{Appender}} class, also provided by Hadoop, called 
> {{EventCounter}}. 
> We should add some info how to enable this (or maybe even enable it by 
> default?).
> The appender needs to be added in two places, shown here:
> {noformat}
> hbase.root.logger=INFO,console
> ...
> # Define the root logger to the system property "hbase.root.logger".
> log4j.rootLogger=${hbase.root.logger}, EventCounter
> log4j.appender.EventCounter=org.apache.hadoop.log.metrics.EventCounter
> {noformat}
> We could simply add this commented out akin to the {{hbase-env.sh}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16188) Add EventCounter information to log4j properties file

2017-02-22 Thread Gopi Krishnan Nambiar (JIRA)

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

Gopi Krishnan Nambiar updated HBASE-16188:
--
Status: Open  (was: Patch Available)

> Add EventCounter information to log4j properties file
> -
>
> Key: HBASE-16188
> URL: https://issues.apache.org/jira/browse/HBASE-16188
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 1.2.1
>Reporter: Lars George
>Assignee: Gopi Krishnan Nambiar
>Priority: Minor
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-16188.patch
>
>
> Hadoop's {{JvmMetrics}}, which HBase also is using in Metrics2 and provides 
> it as an MBean, has the ability to count log4j log calls. This is tracked by 
> a special {{Appender}} class, also provided by Hadoop, called 
> {{EventCounter}}. 
> We should add some info how to enable this (or maybe even enable it by 
> default?).
> The appender needs to be added in two places, shown here:
> {noformat}
> hbase.root.logger=INFO,console
> ...
> # Define the root logger to the system property "hbase.root.logger".
> log4j.rootLogger=${hbase.root.logger}, EventCounter
> log4j.appender.EventCounter=org.apache.hadoop.log.metrics.EventCounter
> {noformat}
> We could simply add this commented out akin to the {{hbase-env.sh}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (HBASE-17679) Log arguments passed to hbck

2017-02-22 Thread Esteban Gutierrez (JIRA)
Esteban Gutierrez created HBASE-17679:
-

 Summary: Log arguments passed to hbck
 Key: HBASE-17679
 URL: https://issues.apache.org/jira/browse/HBASE-17679
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez
Priority: Trivial


Sometimes hbck arguments get lost and we only end up with the output of hbck. 
This should log some basic info about our arguments passed to hbck for better 
supportability. Additional server side logging will be added later on HBase 
Admin calls in a different JIRA.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-17677:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
5s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
49s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 38s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
14s {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} hadoopcheck {color} | {color:green} 
27m 7s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
48s {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:green}+1{color} | {color:green} unit {color} | {color:green} 98m 44s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
15s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 138m 30s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12854051/HBASE-17677.1.patch |
| JIRA Issue | HBASE-17677 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux f0302af6a0bb 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / f037f23 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5803/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/5803/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>  

[jira] [Updated] (HBASE-17590) Drop cache hint should work for StoreFile write path

2017-02-22 Thread Gary Helmling (JIRA)

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

Gary Helmling updated HBASE-17590:
--
   Resolution: Fixed
Fix Version/s: 1.3.1
   1.4.0
   2.0.0
   Status: Resolved  (was: Patch Available)

Committed to branch-1.3+.

> Drop cache hint should work for StoreFile write path
> 
>
> Key: HBASE-17590
> URL: https://issues.apache.org/jira/browse/HBASE-17590
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Ashu Pachauri
> Fix For: 2.0.0, 1.4.0, 1.3.1
>
> Attachments: HBASE-17590.master.001.patch
>
>
> We have this in the code right now.
> {noformat}
> public Builder withShouldDropCacheBehind(boolean 
> shouldDropCacheBehind/*NOT USED!!*/) {
>   // TODO: HAS NO EFFECT!!! FIX!!
>   return this;
> }
> {noformat}
> Creating jira to track it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (HBASE-17069) RegionServer writes invalid META entries for split daughters in some circumstances

2017-02-22 Thread Abhishek Singh Chouhan (JIRA)

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

Abhishek Singh Chouhan edited comment on HBASE-17069 at 2/22/17 9:42 PM:
-

[~stack] I'm still a bit new to the code. Hope i'm not misunderstanding the 
bits :).
bq. mutations have to be zero to go the 'false' route

>From what i understood we enter the below block only when the walEdit is not 
>empty and we have some cells in the wal edit from the processed mutations. 
>Hope i'm not terribly wrong here.
In Hregion.processRowsWithLocks
if (!walEdit.isEmpty()) {
// we use HLogKey here instead of WALKey directly to support legacy 
coprocessors.
walKey = new HLogKey(this.getRegionInfo().getEncodedNameAsBytes(),
  this.htableDescriptor.getTableName(), WALKey.NO_SEQUENCE_ID, now,
  processor.getClusterIds(), nonceGroup, nonce, mvcc);
txid = this.wal.append(this.htableDescriptor, this.getRegionInfo(),
walKey, walEdit, false); //this was false before the patch
  }

bq. I wonder why the hregioninfo previously written doesn't 'shine through'... 
is the update of location writing null into the hregioninfo cell or is the read 
not allowing old versions of the hregioninfo cell in hbase:meta?

During the merge we send a multi that deletes the rows which had the 
hregioninfo and never add it back.


was (Author: abhishek.chouhan):
[~stack] I'm still a bit new to the code. Hope i'm not misunderstanding the 
bits.
bq. mutations have to be zero to go the 'false' route

>From what i understood we enter the below block only when the walEdit is not 
>empty and we have some cells in the wal edit from the processed mutations. 
>Hope i'm not terribly wrong here.
In Hregion.processRowsWithLocks
if (!walEdit.isEmpty()) {
// we use HLogKey here instead of WALKey directly to support legacy 
coprocessors.
walKey = new HLogKey(this.getRegionInfo().getEncodedNameAsBytes(),
  this.htableDescriptor.getTableName(), WALKey.NO_SEQUENCE_ID, now,
  processor.getClusterIds(), nonceGroup, nonce, mvcc);
txid = this.wal.append(this.htableDescriptor, this.getRegionInfo(),
walKey, walEdit, false); //this was false before the patch
  }

bq. I wonder why the hregioninfo previously written doesn't 'shine through'... 
is the update of location writing null into the hregioninfo cell or is the read 
not allowing old versions of the hregioninfo cell in hbase:meta?

During the merge we send a multi that deletes the rows which had the 
hregioninfo and never add it back.

> RegionServer writes invalid META entries for split daughters in some 
> circumstances
> --
>
> Key: HBASE-17069
> URL: https://issues.apache.org/jira/browse/HBASE-17069
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>Reporter: Andrew Purtell
>Assignee: Abhishek Singh Chouhan
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5
>
> Attachments: daughter_1_d55ef81c2f8299abbddfce0445067830.log, 
> daughter_2_08629d59564726da2497f70451aafcdb.log, 
> HBASE-17069.branch-1.3.001.patch, HBASE-17069.branch-1.3.002.patch, 
> HBASE-17069.master.001.patch, logs.tar.gz, 
> parent-393d2bfd8b1c52ce08540306659624f2.log
>
>
> I have been seeing frequent ITBLL failures testing various versions of 1.2.x. 
> Over the lifetime of 1.2.x the following issues have been fixed:
> - HBASE-15315 (Remove always set super user call as high priority)
> - HBASE-16093 (Fix splits failed before creating daughter regions leave meta 
> inconsistent)
> And this one is pending:
> - HBASE-17044 (Fix merge failed before creating merged region leaves meta 
> inconsistent)
> I can apply all of the above to branch-1.2 and still see this failure: 
> *The life of stillborn region d55ef81c2f8299abbddfce0445067830*
> *Master sees SPLITTING_NEW*
> {noformat}
> 2016-11-08 04:23:21,186 INFO  [AM.ZK.Worker-pool2-t82] master.RegionStates: 
> Transition null to {d55ef81c2f8299abbddfce0445067830 state=SPLITTING_NEW, 
> ts=1478579001186, server=node-3.cluster,16020,1478578389506}
> {noformat}
> *The RegionServer creates it*
> {noformat}
> 2016-11-08 04:23:26,035 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for GomnU: blockCache=LruBlockCache{blockCount=34, 
> currentSize=14996112, freeSize=12823716208, maxSize=12838712320, 
> heapSize=14996112, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> 

[jira] [Commented] (HBASE-17069) RegionServer writes invalid META entries for split daughters in some circumstances

2017-02-22 Thread Abhishek Singh Chouhan (JIRA)

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

Abhishek Singh Chouhan commented on HBASE-17069:


[~stack] I'm still a bit new to the code. Hope i'm not misunderstanding the 
bits.
bq. mutations have to be zero to go the 'false' route

>From what i understood we enter the below block only when the walEdit is not 
>empty and we have some cells in the wal edit from the processed mutations. 
>Hope i'm not terribly wrong here.
In Hregion.processRowsWithLocks
if (!walEdit.isEmpty()) {
// we use HLogKey here instead of WALKey directly to support legacy 
coprocessors.
walKey = new HLogKey(this.getRegionInfo().getEncodedNameAsBytes(),
  this.htableDescriptor.getTableName(), WALKey.NO_SEQUENCE_ID, now,
  processor.getClusterIds(), nonceGroup, nonce, mvcc);
txid = this.wal.append(this.htableDescriptor, this.getRegionInfo(),
walKey, walEdit, false); //this was false before the patch
  }

bq. I wonder why the hregioninfo previously written doesn't 'shine through'... 
is the update of location writing null into the hregioninfo cell or is the read 
not allowing old versions of the hregioninfo cell in hbase:meta?

During the merge we send a multi that deletes the rows which had the 
hregioninfo and never add it back.

> RegionServer writes invalid META entries for split daughters in some 
> circumstances
> --
>
> Key: HBASE-17069
> URL: https://issues.apache.org/jira/browse/HBASE-17069
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>Reporter: Andrew Purtell
>Assignee: Abhishek Singh Chouhan
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5
>
> Attachments: daughter_1_d55ef81c2f8299abbddfce0445067830.log, 
> daughter_2_08629d59564726da2497f70451aafcdb.log, 
> HBASE-17069.branch-1.3.001.patch, HBASE-17069.branch-1.3.002.patch, 
> HBASE-17069.master.001.patch, logs.tar.gz, 
> parent-393d2bfd8b1c52ce08540306659624f2.log
>
>
> I have been seeing frequent ITBLL failures testing various versions of 1.2.x. 
> Over the lifetime of 1.2.x the following issues have been fixed:
> - HBASE-15315 (Remove always set super user call as high priority)
> - HBASE-16093 (Fix splits failed before creating daughter regions leave meta 
> inconsistent)
> And this one is pending:
> - HBASE-17044 (Fix merge failed before creating merged region leaves meta 
> inconsistent)
> I can apply all of the above to branch-1.2 and still see this failure: 
> *The life of stillborn region d55ef81c2f8299abbddfce0445067830*
> *Master sees SPLITTING_NEW*
> {noformat}
> 2016-11-08 04:23:21,186 INFO  [AM.ZK.Worker-pool2-t82] master.RegionStates: 
> Transition null to {d55ef81c2f8299abbddfce0445067830 state=SPLITTING_NEW, 
> ts=1478579001186, server=node-3.cluster,16020,1478578389506}
> {noformat}
> *The RegionServer creates it*
> {noformat}
> 2016-11-08 04:23:26,035 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for GomnU: blockCache=LruBlockCache{blockCount=34, 
> currentSize=14996112, freeSize=12823716208, maxSize=12838712320, 
> heapSize=14996112, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,038 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for big: blockCache=LruBlockCache{blockCount=34, 
> currentSize=14996112, freeSize=12823716208, maxSize=12838712320, 
> heapSize=14996112, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,442 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for meta: blockCache=LruBlockCache{blockCount=63, 
> currentSize=17187656, freeSize=12821524664, maxSize=12838712320, 
> heapSize=17187656, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,713 INFO  
> 

[jira] [Commented] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors

2017-02-22 Thread Appy (JIRA)

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

Appy commented on HBASE-17312:
--

Thanks [~stack] for the review. Replied to comments in RB.
Waiting today if anyone else might want to review it too. Otherwise, will 
commit tomorrow.

> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
>  Labels: incompatible
> Attachments: HBASE-17312.master.001.patch, 
> HBASE-17312.master.001.patch, HBASE-17312.master.002.patch
>
>
> In cases where one might need to use multiple observers, say region, master 
> and regionserver; and the fact that only one class can be extended, it gives 
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
>   extends BaseRegionObserver
>   implements MasterObserver
> class AccessController
>   extends BaseMasterAndRegionObserver
>   implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
>  There is an example of simple case too where the current design fails.
>  Say only one observer is needed by the coprocessor, but the design doesn't 
> permit extending even that single observer (see RSGroupAdminEndpoint), that 
> leads to full copy of Base...Observer class into coprocessor class leading to 
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless 
> functions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17312) [JDK8] Use default method for Observer Coprocessors

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17312:
---

+1 This is excellent cleanup. A few small things in rb that can go in on commit.

> [JDK8] Use default method for Observer Coprocessors
> ---
>
> Key: HBASE-17312
> URL: https://issues.apache.org/jira/browse/HBASE-17312
> Project: HBase
>  Issue Type: Sub-task
>  Components: Coprocessors
>Affects Versions: 2.0.0
>Reporter: Guanghao Zhang
>Assignee: Appy
>  Labels: incompatible
> Attachments: HBASE-17312.master.001.patch, 
> HBASE-17312.master.001.patch, HBASE-17312.master.002.patch
>
>
> In cases where one might need to use multiple observers, say region, master 
> and regionserver; and the fact that only one class can be extended, it gives 
> rise to following pattern:
> {noformat}
> public class BaseMasterAndRegionObserver
>   extends BaseRegionObserver
>   implements MasterObserver
> class AccessController
>   extends BaseMasterAndRegionObserver
>   implements RegionServerObserver
> {noformat}
> were BaseMasterAndRegionObserver is full copy of BaseMasterObserver.
>  There is an example of simple case too where the current design fails.
>  Say only one observer is needed by the coprocessor, but the design doesn't 
> permit extending even that single observer (see RSGroupAdminEndpoint), that 
> leads to full copy of Base...Observer class into coprocessor class leading to 
> 1000s of lines of code and this ugly mix of 5 main functions with 100 useless 
> functions.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17590) Drop cache hint should work for StoreFile write path

2017-02-22 Thread Gary Helmling (JIRA)

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

Gary Helmling commented on HBASE-17590:
---

+1.  I'll commit shortly.

> Drop cache hint should work for StoreFile write path
> 
>
> Key: HBASE-17590
> URL: https://issues.apache.org/jira/browse/HBASE-17590
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Ashu Pachauri
> Attachments: HBASE-17590.master.001.patch
>
>
> We have this in the code right now.
> {noformat}
> public Builder withShouldDropCacheBehind(boolean 
> shouldDropCacheBehind/*NOT USED!!*/) {
>   // TODO: HAS NO EFFECT!!! FIX!!
>   return this;
> }
> {noformat}
> Creating jira to track it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17647) OffheapKeyValue#heapSize() implementation is wrong

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17647:
---

bq. Ya old 'size' is what dataSize now. dataSize might be in on heap or off 
heap.. heapSize is tracks total heap space occupied by all cells. This includes 
cell POJO heap overheads and if a cell is on heap, the total length of this 
cells key + value which resides in on heap area any way.

Add this in as a comment on commit.

+1

> OffheapKeyValue#heapSize() implementation is wrong
> --
>
> Key: HBASE-17647
> URL: https://issues.apache.org/jira/browse/HBASE-17647
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0
>
> Attachments: HBASE-17647.patch, HBASE-17647_V2.patch, 
> HBASE-17647_V3.patch
>
>
> We consider the key and data lengths also even though the data is actually in 
> off heap area.  We should correct it.
> The impact will be at ScannerContext limit tracking where we use heapSize of 
> cells to account the result size.  So my proposal is to consider the cells 
> length and heap size in Limit tracking and accounting.  We have a 
> maxResultSize which defaults to 2MB.  When the sum of all cell's data size 
> reaches 'maxResultSize'  OR the sum of all cell's heap size reaches 
> 'maxResultSize' , we need to send back the RPC response



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17677:
---

+1

Thanks [~busbey] Good test.

> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Sean Busbey (JIRA)

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

Sean Busbey updated HBASE-17677:

Attachment: HBASE-17677.1.patch

-01

  - add tests for sunny day wal path parsing and a test with stand-alone test 
paths we've used
  - add handling of the other way ServerName parsing can fail due to guava

> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17677) ServerName parsing from directory name should be more robust to errors from guava's HostAndPort

2017-02-22 Thread Sean Busbey (JIRA)

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

Sean Busbey updated HBASE-17677:

Status: Patch Available  (was: In Progress)

> ServerName parsing from directory name should be more robust to errors from 
> guava's HostAndPort
> ---
>
> Key: HBASE-17677
> URL: https://issues.apache.org/jira/browse/HBASE-17677
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 2.0.0
>
> Attachments: HBASE-17677.1.patch
>
>
> our internal Address facade over HostAndPort directly passes on any failures 
> from the underlying Guava implementation. Right now when we parse a 
> ServerName from a WAL directory we properly handle if guava gives us an 
> IllegalArgumentException but we do not handle if it gives us a 
> IllegalStateException. e.g. it uses the former for "I couldn't parse anything 
> out of this string" and the latter for "I parsed a host name but didn't see a 
> port".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17069) RegionServer writes invalid META entries for split daughters in some circumstances

2017-02-22 Thread stack (JIRA)

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

stack commented on HBASE-17069:
---

Thanks [~abhishek.chouhan] I am enjoying reading your debug journeys. A 
miscounting of sequenceid

bq. The mutations are not empty, however we still were going the route of 
appending with inMemstore as false.

Am I reading in the wrong place, because seems like mutations have to be zero 
to go the 'false' route.

Its called PONR because along w/ the writes to hbase:meta, we send a prayer 
hoping we get to the next cleanup step (The new AM should help here).

bq. Now during the HRegionServer.postOpenDeployTasks we use 
MetaTableAccessor.updateRegionLocation() which doesn't have the hregioninfo

I wonder why the hregioninfo previously written doesn't 'shine through'... is 
the update of location writing null into the hregioninfo cell or is the read 
not allowing old versions of the hregioninfo cell in hbase:meta?

bq. I think we should handle mergingnew the same way as splittingnew. 

Yes. The states are myriad. There will be holes and takes someone of your 
diligence to identify them.



> RegionServer writes invalid META entries for split daughters in some 
> circumstances
> --
>
> Key: HBASE-17069
> URL: https://issues.apache.org/jira/browse/HBASE-17069
> Project: HBase
>  Issue Type: Bug
>  Components: wal
>Affects Versions: 2.0.0, 1.3.0, 1.4.0, 1.2.4
>Reporter: Andrew Purtell
>Assignee: Abhishek Singh Chouhan
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.1, 1.2.5
>
> Attachments: daughter_1_d55ef81c2f8299abbddfce0445067830.log, 
> daughter_2_08629d59564726da2497f70451aafcdb.log, 
> HBASE-17069.branch-1.3.001.patch, HBASE-17069.branch-1.3.002.patch, 
> HBASE-17069.master.001.patch, logs.tar.gz, 
> parent-393d2bfd8b1c52ce08540306659624f2.log
>
>
> I have been seeing frequent ITBLL failures testing various versions of 1.2.x. 
> Over the lifetime of 1.2.x the following issues have been fixed:
> - HBASE-15315 (Remove always set super user call as high priority)
> - HBASE-16093 (Fix splits failed before creating daughter regions leave meta 
> inconsistent)
> And this one is pending:
> - HBASE-17044 (Fix merge failed before creating merged region leaves meta 
> inconsistent)
> I can apply all of the above to branch-1.2 and still see this failure: 
> *The life of stillborn region d55ef81c2f8299abbddfce0445067830*
> *Master sees SPLITTING_NEW*
> {noformat}
> 2016-11-08 04:23:21,186 INFO  [AM.ZK.Worker-pool2-t82] master.RegionStates: 
> Transition null to {d55ef81c2f8299abbddfce0445067830 state=SPLITTING_NEW, 
> ts=1478579001186, server=node-3.cluster,16020,1478578389506}
> {noformat}
> *The RegionServer creates it*
> {noformat}
> 2016-11-08 04:23:26,035 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for GomnU: blockCache=LruBlockCache{blockCount=34, 
> currentSize=14996112, freeSize=12823716208, maxSize=12838712320, 
> heapSize=14996112, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,038 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for big: blockCache=LruBlockCache{blockCount=34, 
> currentSize=14996112, freeSize=12823716208, maxSize=12838712320, 
> heapSize=14996112, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,442 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for meta: blockCache=LruBlockCache{blockCount=63, 
> currentSize=17187656, freeSize=12821524664, maxSize=12838712320, 
> heapSize=17187656, minSize=12196776960, minFactor=0.95, multiSize=6098388480, 
> multiFactor=0.5, singleSize=3049194240, singleFactor=0.25}, 
> cacheDataOnRead=true, cacheDataOnWrite=false, cacheIndexesOnWrite=false, 
> cacheBloomsOnWrite=false, cacheEvictOnClose=false, cacheDataCompressed=false, 
> prefetchOnOpen=false
> 2016-11-08 04:23:26,713 INFO  
> [StoreOpener-d55ef81c2f8299abbddfce0445067830-1] hfile.CacheConfig: Created 
> cacheConfig for nwmrW: blockCache=LruBlockCache{blockCount=96, 
> currentSize=19178440, freeSize=12819533880, maxSize=12838712320, 
> heapSize=19178440, minSize=12196776960, 

[jira] [Commented] (HBASE-17647) OffheapKeyValue#heapSize() implementation is wrong

2017-02-22 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-17647:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 19s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s 
{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
58s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
32s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 19s 
{color} | {color:red} hbase-prefix-tree in master has 1 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 10s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 1s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 0s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
32s {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} hadoopcheck {color} | {color:green} 
28m 13s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 9s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 1s 
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 24s 
{color} | {color:green} hbase-prefix-tree in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 97m 23s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
39s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 146m 42s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12854001/HBASE-17647_V3.patch |
| JIRA Issue | HBASE-17647 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 0ec42ed67cd7 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / f037f23 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| findbugs | 

  1   2   >