[jira] [Created] (HBASE-16119) Procedure v2 - Reimplement merge

2016-06-26 Thread Matteo Bertozzi (JIRA)
Matteo Bertozzi created HBASE-16119:
---

 Summary: Procedure v2 - Reimplement merge
 Key: HBASE-16119
 URL: https://issues.apache.org/jira/browse/HBASE-16119
 Project: HBase
  Issue Type: Sub-task
  Components: proc-v2, Region Assignment
Affects Versions: 2.0.0
Reporter: Matteo Bertozzi


use the proc-v2 state machine for merge. also update the logic to have a single 
meta-writer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14551) Procedure v2 - Reimplement split

2016-06-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-14551:

Parent Issue: HBASE-14350  (was: HBASE-14351)

> Procedure v2 - Reimplement split
> 
>
> Key: HBASE-14551
> URL: https://issues.apache.org/jira/browse/HBASE-14551
> Project: HBase
>  Issue Type: Sub-task
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Stephen Yuan Jiang
>Priority: Minor
> Fix For: 2.0.0
>
>
> use the proc-v2 state machine for split. also update the logic to have a 
> single meta-writer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14552) Procedure v2 - Reimplement DispatchMergingRegionHandler

2016-06-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-14552:

Description: use the proc-v2 state machine for 
DispatchMergingRegionHandler.  (was: use the proc-v2 state machine for merge. 
also update the logic to have a single meta-writer.)

> Procedure v2 - Reimplement DispatchMergingRegionHandler
> ---
>
> Key: HBASE-14552
> URL: https://issues.apache.org/jira/browse/HBASE-14552
> Project: HBase
>  Issue Type: Sub-task
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Stephen Yuan Jiang
> Attachments: HBASE-14552.v0-master.patch
>
>
> use the proc-v2 state machine for DispatchMergingRegionHandler.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-14552) Procedure v2 - Reimplement DispatchMergingRegionHandler

2016-06-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-14552:

Summary: Procedure v2 - Reimplement DispatchMergingRegionHandler  (was: 
Procedure v2 - Reimplement merge)

> Procedure v2 - Reimplement DispatchMergingRegionHandler
> ---
>
> Key: HBASE-14552
> URL: https://issues.apache.org/jira/browse/HBASE-14552
> Project: HBase
>  Issue Type: Sub-task
>  Components: proc-v2
>Affects Versions: 2.0.0
>Reporter: Matteo Bertozzi
>Assignee: Stephen Yuan Jiang
> Attachments: HBASE-14552.v0-master.patch
>
>
> use the proc-v2 state machine for merge. also update the logic to have a 
> single meta-writer.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-13701) Consolidate SecureBulkLoadEndpoint into HBase core as default for bulk load

2016-06-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-13701:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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 8s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 3s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 27s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m 
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m 
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 
18s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 31s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 17s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m 9s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m 9s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m 9s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 27s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 27s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 27s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 9m 
3s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
42s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
26m 47s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 0m 
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m 
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 25s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 16s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 20s 
{color} | {color:green} hbase-protocol in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 45s 
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 56s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | 

[jira] [Commented] (HBASE-16055) PutSortReducer loses any Visibility/acl attribute set on the Puts

2016-06-26 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan commented on HBASE-16055:


[~apurtell]
You may need this in 0.98 also?

> PutSortReducer loses any Visibility/acl attribute set on the Puts 
> --
>
> Key: HBASE-16055
> URL: https://issues.apache.org/jira/browse/HBASE-16055
> Project: HBase
>  Issue Type: Bug
>  Components: security
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Critical
> Fix For: 2.0.0, 1.0.4, 1.4.0, 0.98.21
>
> Attachments: HBASE-16055_1.patch, HBASE-16055_2.patch
>
>
> Based on a user discussion, I think as the user pointed out rightly, when a 
> PutSortReducer is used any visibility attribute or external attribute set on 
> the Put will be lost as we create KVs out of the cells in the puts whereas 
> the ACL and visibility are all set as Attributes. 
> In TextSortReducer we tend to read the information we tend to read the 
> information from the parsed line but here in PutSortReducer we don't do it. I 
> think this problem should be in all the existing versions where we support 
> Tags. Correct me if am wrong here. 
> [~anoop.hbase], [~andrew.purt...@gmail.com]?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread Mikhail Antonov (JIRA)

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

Mikhail Antonov commented on HBASE-16118:
-

Thanks [~anoopsamjohn] and [~ram_krish]

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
>Assignee: ramkrishna.s.vasudevan
> Fix For: 1.4.0
>
> Attachments: HBASE-16055_branch1_ignoretest.patch
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread Mikhail Antonov (JIRA)

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

Mikhail Antonov commented on HBASE-16118:
-

The patch for HBASE-16055 has only been committed to master, was it not? Hm. 
I'd prefer to not add ignored test, but probably that's what we should do to 
unbreak the build until the problem is fixed?

+1 for branch-1 and master.

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
>Assignee: ramkrishna.s.vasudevan
> Fix For: 1.4.0
>
> Attachments: HBASE-16055_branch1_ignoretest.patch
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan updated HBASE-16118:
---
Resolution: Fixed
  Assignee: ramkrishna.s.vasudevan
Status: Resolved  (was: Patch Available)

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
>Assignee: ramkrishna.s.vasudevan
> Fix For: 1.4.0
>
> Attachments: HBASE-16055_branch1_ignoretest.patch
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan updated HBASE-16118:
---
Status: Patch Available  (was: Open)

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
> Fix For: 1.4.0
>
> Attachments: HBASE-16055_branch1_ignoretest.patch
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan updated HBASE-16118:
---
Attachment: HBASE-16055_branch1_ignoretest.patch

Will commit this patch unless objections.

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
> Fix For: 1.4.0
>
> Attachments: HBASE-16055_branch1_ignoretest.patch
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan commented on HBASE-16118:


I commented out the PutSortReducer and allowed the test to run without 
PutSortReducer which is nothing but existing test case way.  The same place 
fails in the test case. So I will add @Ignore tag only.

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
> Fix For: 1.4.0
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread ramkrishna.s.vasudevan (JIRA)

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

ramkrishna.s.vasudevan commented on HBASE-16118:


Ya I am checking it. Infact adding @Ignore is better because the failure is 
related to locality.  I will cross check once and then add @Ignore tag.

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
> Fix For: 1.4.0
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16112) TestFlushSnapshotFromClient and TestMobFlushSnapshotFromClient are flaky

2016-06-26 Thread Jingcheng Du (JIRA)

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

Jingcheng Du updated HBASE-16112:
-
Summary: TestFlushSnapshotFromClient and TestMobFlushSnapshotFromClient are 
flaky  (was: TestFlushSnapshotFromClient is flaky)

> TestFlushSnapshotFromClient and TestMobFlushSnapshotFromClient are flaky
> 
>
> Key: HBASE-16112
> URL: https://issues.apache.org/jira/browse/HBASE-16112
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Jingcheng Du
>Priority: Minor
> Attachments: TestFlushSnapshotFromClient-2353.out, 
> TestMobFlushSnapshotFromClient-2353.out, testSnapshotStateAfterMerge-2353.out
>
>
> On recent QA runs, TestMobFlushSnapshotFromClient failed twice.
> https://builds.apache.org/job/PreCommit-HBASE-Build/2360/#showFailuresLink
> https://builds.apache.org/job/PreCommit-HBASE-Build/2353/artifact/patchprocess/patch-unit-hbase-server.txt
> {code}
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
>   Run 1: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123->Object.wait:-2
>  » TestTimedOut
>   Run 2: 
> TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
>  » 
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.testSnapshotStateAfterMerge(org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient)
>   Run 1: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.testSnapshotStateAfterMerge:335->TestFlushSnapshotFromClient.waitRegionsAfterMerge:526
>  » RetriesExhausted
>   Run 2: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123 » 
> InterruptedIO
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16112) TestFlushSnapshotFromClient is flaky

2016-06-26 Thread Jingcheng Du (JIRA)

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

Jingcheng Du updated HBASE-16112:
-
Summary: TestFlushSnapshotFromClient is flaky  (was: 
TestMobFlushSnapshotFromClient is flaky)

> TestFlushSnapshotFromClient is flaky
> 
>
> Key: HBASE-16112
> URL: https://issues.apache.org/jira/browse/HBASE-16112
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Jingcheng Du
>Priority: Minor
> Attachments: TestFlushSnapshotFromClient-2353.out, 
> TestMobFlushSnapshotFromClient-2353.out, testSnapshotStateAfterMerge-2353.out
>
>
> On recent QA runs, TestMobFlushSnapshotFromClient failed twice.
> https://builds.apache.org/job/PreCommit-HBASE-Build/2360/#showFailuresLink
> https://builds.apache.org/job/PreCommit-HBASE-Build/2353/artifact/patchprocess/patch-unit-hbase-server.txt
> {code}
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
>   Run 1: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123->Object.wait:-2
>  » TestTimedOut
>   Run 2: 
> TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
>  » 
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.testSnapshotStateAfterMerge(org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient)
>   Run 1: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.testSnapshotStateAfterMerge:335->TestFlushSnapshotFromClient.waitRegionsAfterMerge:526
>  » RetriesExhausted
>   Run 2: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123 » 
> InterruptedIO
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread Anoop Sam John (JIRA)

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

Anoop Sam John commented on HBASE-16118:


Test newly added by  HBASE-16055.   This test class is with most of the tests 
being @Ignore.
May be we should not be adding the new test also?

> TestHFileOutputFormat2 is broken
> 
>
> Key: HBASE-16118
> URL: https://issues.apache.org/jira/browse/HBASE-16118
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.4.0
>Reporter: Mikhail Antonov
> Fix For: 1.4.0
>
>
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer
> See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink
> Error Message
> expected:<100> but was:<0>
> Stacktrace
> java.lang.AssertionError: expected:<100> but was:<0>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
>   at 
> org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (HBASE-16112) TestMobFlushSnapshotFromClient is flaky

2016-06-26 Thread Jingcheng Du (JIRA)

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

Jingcheng Du reassigned HBASE-16112:


Assignee: Jingcheng Du

> TestMobFlushSnapshotFromClient is flaky
> ---
>
> Key: HBASE-16112
> URL: https://issues.apache.org/jira/browse/HBASE-16112
> Project: HBase
>  Issue Type: Test
>Reporter: Ted Yu
>Assignee: Jingcheng Du
>Priority: Minor
> Attachments: TestFlushSnapshotFromClient-2353.out, 
> TestMobFlushSnapshotFromClient-2353.out, testSnapshotStateAfterMerge-2353.out
>
>
> On recent QA runs, TestMobFlushSnapshotFromClient failed twice.
> https://builds.apache.org/job/PreCommit-HBASE-Build/2360/#showFailuresLink
> https://builds.apache.org/job/PreCommit-HBASE-Build/2353/artifact/patchprocess/patch-unit-hbase-server.txt
> {code}
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
>   Run 1: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123->Object.wait:-2
>  » TestTimedOut
>   Run 2: 
> TestMobFlushSnapshotFromClient.org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient
>  » 
> org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient.testSnapshotStateAfterMerge(org.apache.hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient)
>   Run 1: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.testSnapshotStateAfterMerge:335->TestFlushSnapshotFromClient.waitRegionsAfterMerge:526
>  » RetriesExhausted
>   Run 2: 
> TestMobFlushSnapshotFromClient>TestFlushSnapshotFromClient.tearDown:123 » 
> InterruptedIO
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-14007) Writing to table through MR should fail upfront if table does not exist/disabled

2016-06-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-14007:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
51s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s 
{color} | {color:green} master passed with JDK v1.7.0_80 {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 44s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 44s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
53s {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} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
25m 54s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 92m 54s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
16s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 133m 51s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.snapshot.TestMobFlushSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12813577/HBASE-14007.master.002.patch
 |
| JIRA Issue | HBASE-14007 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP 
PREEMPT Wed Sep 3 21:56:12 UTC 2014 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 / fc4b8aa |
| Default Java | 1.7.0_80 |
| Multi-JDK versions |  /home/jenkins/tools/java/jdk1.8.0:1.8.0 
/home/jenkins/jenkins-slave/tools/hudson.model.JDK/JDK_1.7_latest_:1.7.0_80 |
| 

[jira] [Created] (HBASE-16118) TestHFileOutputFormat2 is broken

2016-06-26 Thread Mikhail Antonov (JIRA)
Mikhail Antonov created HBASE-16118:
---

 Summary: TestHFileOutputFormat2 is broken
 Key: HBASE-16118
 URL: https://issues.apache.org/jira/browse/HBASE-16118
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 1.4.0
Reporter: Mikhail Antonov
 Fix For: 1.4.0


org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer

See https://builds.apache.org/job/HBase-1.4/250/#showFailuresLink

Error Message

expected:<100> but was:<0>
Stacktrace

java.lang.AssertionError: expected:<100> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.doIncrementalLoadTest(TestHFileOutputFormat2.java:636)
at 
org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat2.testMRIncrementalLoadWithPutSortReducer(TestHFileOutputFormat2.java:536)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-13701) Consolidate SecureBulkLoadEndpoint into HBase core as default for bulk load

2016-06-26 Thread Jerry He (JIRA)

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

Jerry He updated HBASE-13701:
-
Attachment: HBASE-13701-v2.patch

Attached v2.
Fixed the test failures TestMetricsConnection, TestRegionMergeTransaction (Set 
hbase.bulkload.staging.dir in HBaseCommonTestingUtility).
Addressed Ted's comments in the RB.

> Consolidate SecureBulkLoadEndpoint into HBase core as default for bulk load
> ---
>
> Key: HBASE-13701
> URL: https://issues.apache.org/jira/browse/HBASE-13701
> Project: HBase
>  Issue Type: Improvement
>Reporter: Jerry He
>Assignee: Jerry He
> Fix For: 2.0.0
>
> Attachments: HBASE-13701-v1.patch, HBASE-13701-v2.patch
>
>
> HBASE-12052 makes SecureBulkLoadEndpoint work in a non-secure env to solve 
> HDFS permission issues.
> We have encountered some of the permission issues and have to use this 
> SecureBulkLoadEndpoint to workaround issues.
> We should  probably consolidate SecureBulkLoadEndpoint into HBase core as 
> default for bulk load since it is able to handle both secure Kerberos and 
> non-secure cases.
> Maintaining two versions of bulk load implementation is also a cause of 
> confusion, and having to explicitly set it is also inconvenient.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16117) Fix Connection leak in mapred.TableOutputFormat

2016-06-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-16117:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 11s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 51s 
{color} | {color:green} master passed with JDK v1.7.0_80 {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 
26s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 9s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
5s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 11s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 50s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 50s 
{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} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
26m 28s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
19s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 57s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 94m 45s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
29s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 143m 48s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.util.TestMergeTool |
|   | hadoop.hbase.mapred.TestTableMapReduce |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12813574/hbase-16117.patch |
| JIRA Issue | HBASE-16117 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux asf900.gq1.ygridcore.net 

[jira] [Updated] (HBASE-14007) Writing to table through MR should fail upfront if table does not exist/disabled

2016-06-26 Thread Thiruvel Thirumoolan (JIRA)

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

Thiruvel Thirumoolan updated HBASE-14007:
-
Attachment: HBASE-14007.master.002.patch

Tess passes locally. It passes with the precommit also, but for some reason 
seems to fail with xml parsing error of the results. Lemme give it another 
shot, reuploading same patch with bumped up patch number. Lets see.

> Writing to table through MR should fail upfront if table does not 
> exist/disabled
> 
>
> Key: HBASE-14007
> URL: https://issues.apache.org/jira/browse/HBASE-14007
> Project: HBase
>  Issue Type: Improvement
>  Components: mapreduce
>Affects Versions: 1.1.1
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
>Priority: Minor
>  Labels: mapreduce
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-14007.master.001.patch, 
> HBASE-14007.master.002.patch, HBASE-14007.patch
>
>
> TableOutputFormat.checkOutputSpecs() needs to be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-15946) Eliminate possible security concerns in RS web UI's store file metrics

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-15946:
---
Fix Version/s: 0.98.21
   1.4.0
   2.0.0

> Eliminate possible security concerns in RS web UI's store file metrics
> --
>
> Key: HBASE-15946
> URL: https://issues.apache.org/jira/browse/HBASE-15946
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.3.0, 1.2.1
>Reporter: Sean Mackrory
>Assignee: Sean Mackrory
> Fix For: 2.0.0, 1.3.0, 1.4.0, 1.2.2, 0.98.21
>
> Attachments: HBASE-15946-branch-1.3-mantonov.diff, 
> HBASE-15946-v1.patch, HBASE-15946-v2.patch, HBASE-15946-v3.patch
>
>
> More from static code analysis: it warns about the invoking of a separate 
> command ("hbase hfile -s -f ...") as a possible security issue in 
> hbase-server/src/main/resources/hbase-webapps/regionserver/storeFile.jsp.
> It looks to me like one cannot inject arbitrary shell script or even 
> arbitrary arguments: ProcessBuilder makes that fairly safe and only allows 
> the user to specify the argument that comes after -f. However that does 
> potentially allow them to have the daemon's user access files they shouldn't 
> be able to touch, albeit only for reading.
> To more explicitly eliminate any threats here, we should add some validation 
> that the file is at least within HBase's root directory and use the Java API 
> directly instead of invoking a separate executable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16033) Add more details in logging of responseTooSlow/TooLarge

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-16033:
---
Fix Version/s: 0.98.21
   1.4.0

> Add more details in logging of responseTooSlow/TooLarge
> ---
>
> Key: HBASE-16033
> URL: https://issues.apache.org/jira/browse/HBASE-16033
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.2.1
>Reporter: Yu Li
>Assignee: Yu Li
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21
>
> Attachments: HBASE-16033.patch, HBASE-16033.patch, HBASE-16033.patch
>
>
> Currently the log message when responseTooSlow/TooLarge is like:
> {noformat}
> 2016-06-08 12:18:04,363 WARN  
> [B.defaultRpcServer.handler=127,queue=10,port=16020]
> ipc.RpcServer: (responseTooSlow): 
> {"processingtimems":13125,"call":"Multi(org.apache.hadoop.hbase.protobuf.generated.ClientProtos$MultiRequest)",
> "client":"11.251.158.22:36331","starttimems":1465359471238,"queuetimems":1540116,
> "class":"HRegionServer","responsesize":17,"method":"Multi"}
> {noformat}
> which is kind of helpless for debugging since we don't know on which 
> table/region/row the request is against.
> What's more, we could see some if-else check in the {{RpcServer#logResponse}} 
> method which trying to do sth different when the {{param}} includes instance 
> of {{Operation}}, but there's only one place invoking {{logResponse}} and the 
> {{param}} is always an instance of {{Message}}. Checking the change history, 
> I believe this is a left-over cleanup in work of HBASE-8214 
> We will address the above issues, do some cleanup and improve the log just 
> like {{RpcServer$Call#toString}} does to include table/region/row information 
> of the request



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16045) endtime argument for VerifyReplication was incorrectly specified in usage

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-16045:
---
Fix Version/s: 0.98.21

> endtime argument for VerifyReplication was incorrectly specified in usage
> -
>
> Key: HBASE-16045
> URL: https://issues.apache.org/jira/browse/HBASE-16045
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.4.0, 0.98.21
>
> Attachments: 16045.v1.txt, 16045.v2.txt, 16045.v3.txt
>
>
> Working on a customer case where the following was given for verifyrep:
> {code}
> --starttime=145679040 \ 
> --stoptime=145687680
> {code}
> Customer complained that the timestamp of a (sample) row reported as 
> ONLY_IN_PEER_TABLE_ROWS corresponded to time outside the time range.
> The code says:
> {code}
> final String endTimeArgKey = "--endtime=";
> {code}
> It turns out that usage String was wrong:
> {code}
> System.err.println("Usage: verifyrep [--starttime=X]" +
> " [--stoptime=Y] [--families=A]  ");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16090) ResultScanner is not closed in SyncTable#finishRemainingHashRanges()

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-16090:
---
Fix Version/s: 0.98.21

> ResultScanner is not closed in SyncTable#finishRemainingHashRanges()
> 
>
> Key: HBASE-16090
> URL: https://issues.apache.org/jira/browse/HBASE-16090
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.4.0, 0.98.21
>
> Attachments: 16090.v1.txt, 16090.v1.txt
>
>
> Here is related code:
> {code}
>   ResultScanner targetScanner = targetTable.getScanner(scan);
>   for (Result row : targetScanner) {
> targetHasher.hashResult(row);  
>   }
> } // else current batch ends exactly at split end row
> {code}
> targetScanner should be closed upon leaving the if block.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16061) Allow logging to a buffered console

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-16061:
---
Fix Version/s: 0.98.21

> Allow logging to a buffered console
> ---
>
> Key: HBASE-16061
> URL: https://issues.apache.org/jira/browse/HBASE-16061
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 1.2.1
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Fix For: 2.0.0, 1.3.0, 0.98.21
>
> Attachments: HBASE-16061.v1.patch, HBASE-16061.v2.patch
>
>
> We've seen some stalls when logging to the ConsoleLogger that's getting 
> redirected to a file. We should allow people to use a buffered console 
> appender to keep from having stalls when the logging disk is busy.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-15870) Specify columns in REST multi gets

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-15870:
---
Fix Version/s: 0.98.21

> Specify columns in REST multi gets
> --
>
> Key: HBASE-15870
> URL: https://issues.apache.org/jira/browse/HBASE-15870
> Project: HBase
>  Issue Type: Improvement
>  Components: REST
>Reporter: Dean Gurvitz
>Assignee: Matt Warhaftig
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21
>
> Attachments: hbase-15870-v1.patch
>
>
> The REST multi-gets feature currently does not allow specifying only certain 
> columns or column families. Adding support for these should be quite simple 
> and improve the usability of the multi-gets feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-15746) Remove extra RegionCoprocessor preClose() in RSRpcServices#closeRegion

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-15746:
---
Fix Version/s: 0.98.21

> Remove extra RegionCoprocessor preClose() in RSRpcServices#closeRegion
> --
>
> Key: HBASE-15746
> URL: https://issues.apache.org/jira/browse/HBASE-15746
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors, regionserver
>Affects Versions: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 0.98.19
>Reporter: Matteo Bertozzi
>Assignee: Stephen Yuan Jiang
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.0.4, 1.4.0, 1.2.2, 0.98.21
>
> Attachments: HBASE-15746.v1-master.patch
>
>
> The preClose() region coprocessor call gets called 3 times via rpc.
> The first one is when we receive the RPC
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java#L1329
> The second time is when ask the RS to close the region
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java#L2852
> The third time is when the doClose() on the region is executed.
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L1419
> I'm pretty sure the first one can be removed since, there is no code between 
> that and the second call. and they are a copy-paste.
> The second one explicitly says that is to enforce ACLs before starting the 
> operation, which leads me to the fact that the 3rd one in the region gets 
> executed too late in the process. but the region.close() may be called by 
> someone other than the RS, so we should probably leave the preClose() in 
> there (e.g. OpenRegionHandler on failure cleanup). 
> any idea?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16070) Mapreduce Serialization classes do not have Interface audience

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-16070:
---
Fix Version/s: 0.98.21

> Mapreduce Serialization classes do not have Interface audience
> --
>
> Key: HBASE-16070
> URL: https://issues.apache.org/jira/browse/HBASE-16070
> Project: HBase
>  Issue Type: Bug
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0, 1.4.0, 0.98.21
>
> Attachments: HBASE-16070.patch
>
>
> KeyValueSerilization, ResultSerialization and MutationSerialization do not 
> Interface audience. They are exposed interfaces and should be Public if am 
> not wrong.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16085) Add on metric for failed compactions

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-16085:
---
Fix Version/s: 0.98.21

> Add on metric for failed compactions
> 
>
> Key: HBASE-16085
> URL: https://issues.apache.org/jira/browse/HBASE-16085
> Project: HBase
>  Issue Type: Improvement
>Reporter: Elliott Clark
>Assignee: Gary Helmling
> Fix For: 2.0.0, 1.3.0, 1.4.0, 0.98.21
>
> Attachments: HBASE-16085.001.patch, HBASE-16085.002.patch
>
>
> Failing compactions doesn't stop the server so things can go un-noticed for 
> quite a while if there are no metrics.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-26 Thread Ashish Singhi (JIRA)

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

Ashish Singhi commented on HBASE-16087:
---

No, it does not sound feasible to me to create unnecessarily a dummy table in 
production cluster and guarantee that it is always hosted on the master.

bq. so I think number of users affected would be very small 
Agree, may be small but it does affect their clusters.

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch, HBASE-16087.v1.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16087) Replication shouldn't start on a master if if only hosts system tables

2016-06-26 Thread Ashish Singhi (JIRA)

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

Ashish Singhi commented on HBASE-16087:
---

Yes, only system tables are hosted on the master.

> Replication shouldn't start on a master if if only hosts system tables
> --
>
> Key: HBASE-16087
> URL: https://issues.apache.org/jira/browse/HBASE-16087
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
> Attachments: HBASE-16087.patch, HBASE-16087.v1.patch
>
>
> System tables aren't replicated so we shouldn't start up a replication master 
> if there are no user tables on the master.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16117) Fix Connection leak in mapred.TableOutputFormat

2016-06-26 Thread Jonathan Hsieh (JIRA)

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

Jonathan Hsieh updated HBASE-16117:
---
Status: Patch Available  (was: Open)

> Fix Connection leak in mapred.TableOutputFormat 
> 
>
> Key: HBASE-16117
> URL: https://issues.apache.org/jira/browse/HBASE-16117
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Affects Versions: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: hbase-16117.branch-1.patch, hbase-16117.patch
>
>
> Spark seems to instantiate multiple instances of output formats within a 
> single process.  When mapred.TableOutputFormat (not 
> mapreduce.TableOutputFormat) is used, this may cause connection leaks that 
> slowly exhaust the cluster's zk connections.  
> This patch fixes that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16117) Fix Connection leak in mapred.TableOutputFormat

2016-06-26 Thread Jonathan Hsieh (JIRA)

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

Jonathan Hsieh updated HBASE-16117:
---
Attachment: hbase-16117.patch

> Fix Connection leak in mapred.TableOutputFormat 
> 
>
> Key: HBASE-16117
> URL: https://issues.apache.org/jira/browse/HBASE-16117
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Affects Versions: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: hbase-16117.branch-1.patch, hbase-16117.patch
>
>
> Spark seems to instantiate multiple instances of output formats within a 
> single process.  When mapred.TableOutputFormat (not 
> mapreduce.TableOutputFormat) is used, this may cause connection leaks that 
> slowly exhaust the cluster's zk connections.  
> This patch fixes that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16117) Fix Connection leak in mapred.TableOutputFormat

2016-06-26 Thread Jonathan Hsieh (JIRA)

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

Jonathan Hsieh updated HBASE-16117:
---
Summary: Fix Connection leak in mapred.TableOutputFormat   (was: Fix 
Connection leak in mapred.TableOutputFormat when spark uses it. )

> Fix Connection leak in mapred.TableOutputFormat 
> 
>
> Key: HBASE-16117
> URL: https://issues.apache.org/jira/browse/HBASE-16117
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Affects Versions: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: hbase-16117.branch-1.patch
>
>
> Spark seems to instantiate multiple instances of output formats within a 
> single process.  When mapred.TableOutputFormat (not 
> mapreduce.TableOutputFormat) is used, this may cause connection leaks that 
> slowly exhaust the cluster's zk connections.  
> This patch fixes that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16117) Fix Connection leak in mapred.TableOutputFormat when spark uses it.

2016-06-26 Thread Jonathan Hsieh (JIRA)

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

Jonathan Hsieh updated HBASE-16117:
---
Attachment: hbase-16117.branch-1.patch

> Fix Connection leak in mapred.TableOutputFormat when spark uses it. 
> 
>
> Key: HBASE-16117
> URL: https://issues.apache.org/jira/browse/HBASE-16117
> Project: HBase
>  Issue Type: Bug
>  Components: mapreduce
>Affects Versions: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6
>
> Attachments: hbase-16117.branch-1.patch
>
>
> Spark seems to instantiate multiple instances of output formats within a 
> single process.  When mapred.TableOutputFormat (not 
> mapreduce.TableOutputFormat) is used, this may cause connection leaks that 
> slowly exhaust the cluster's zk connections.  
> This patch fixes that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16117) Fix Connection leak in mapred.TableOutputFormat when spark uses it.

2016-06-26 Thread Jonathan Hsieh (JIRA)
Jonathan Hsieh created HBASE-16117:
--

 Summary: Fix Connection leak in mapred.TableOutputFormat when 
spark uses it. 
 Key: HBASE-16117
 URL: https://issues.apache.org/jira/browse/HBASE-16117
 Project: HBase
  Issue Type: Bug
  Components: mapreduce
Affects Versions: 2.0.0, 1.3.0, 1.2.2, 1.1.6
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 2.0.0, 1.3.0, 1.2.2, 1.1.6


Spark seems to instantiate multiple instances of output formats within a single 
process.  When mapred.TableOutputFormat (not mapreduce.TableOutputFormat) is 
used, this may cause connection leaks that slowly exhaust the cluster's zk 
connections.  

This patch fixes that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-14007) Writing to table through MR should fail upfront if table does not exist/disabled

2016-06-26 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-14007:


TestAcidGuarantees is not related to mapreduce.
Does it pass when you run locally ?

> Writing to table through MR should fail upfront if table does not 
> exist/disabled
> 
>
> Key: HBASE-14007
> URL: https://issues.apache.org/jira/browse/HBASE-14007
> Project: HBase
>  Issue Type: Improvement
>  Components: mapreduce
>Affects Versions: 1.1.1
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
>Priority: Minor
>  Labels: mapreduce
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-14007.master.001.patch, HBASE-14007.patch
>
>
> TableOutputFormat.checkOutputSpecs() needs to be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-14007) Writing to table through MR should fail upfront if table does not exist/disabled

2016-06-26 Thread Thiruvel Thirumoolan (JIRA)

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

Thiruvel Thirumoolan commented on HBASE-14007:
--

"hadoop.hbase.TestAcidGuarantees" failure is unrelated to this patch's changes. 
Should I resubmit my patch to get another run?

> Writing to table through MR should fail upfront if table does not 
> exist/disabled
> 
>
> Key: HBASE-14007
> URL: https://issues.apache.org/jira/browse/HBASE-14007
> Project: HBase
>  Issue Type: Improvement
>  Components: mapreduce
>Affects Versions: 1.1.1
>Reporter: Thiruvel Thirumoolan
>Assignee: Thiruvel Thirumoolan
>Priority: Minor
>  Labels: mapreduce
> Fix For: 2.0.0, 1.4.0
>
> Attachments: HBASE-14007.master.001.patch, HBASE-14007.patch
>
>
> TableOutputFormat.checkOutputSpecs() needs to be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16116) .gitignore file contains pattern '*.iml' two times

2016-06-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-16116:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {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} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
25m 57s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
12s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 26m 17s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12813566/HBASE-16116.patch |
| JIRA Issue | HBASE-16116 |
| Optional Tests |  asflicense  |
| uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP 
PREEMPT Wed Sep 3 21:56:12 UTC 2014 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 / fc4b8aa |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/2367/console |
| Powered by | Apache Yetus 0.2.1   http://yetus.apache.org |


This message was automatically generated.



> .gitignore file contains pattern '*.iml' two times
> --
>
> Key: HBASE-16116
> URL: https://issues.apache.org/jira/browse/HBASE-16116
> Project: HBase
>  Issue Type: Improvement
>Reporter: Konstantin Ryakhovskiy
>Priority: Trivial
>  Labels: beginner
> Attachments: HBASE-16116.patch
>
>
> .gitignore file contains pattern '*.iml' two times:
> {code}
> /.arc_jira_lib
> /.externalToolBuilders
> .project
> *.settings/
> .classpath
> /build
> /.idea/
> /logs
> *target/
> *.iml --- first appearance 
> *.orig
> *~
> hbase-*/test
> *.iws
> *.iml --- second appearance 
> *.ipr
> patchprocess/
> dependency-reduced-pom.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16116) .gitignore file contains pattern '*.iml' two times

2016-06-26 Thread Konstantin Ryakhovskiy (JIRA)

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

Konstantin Ryakhovskiy updated HBASE-16116:
---
Summary: .gitignore file contains pattern '*.iml' two times  (was: 
.gitignore file contains '*.iml' two times)

> .gitignore file contains pattern '*.iml' two times
> --
>
> Key: HBASE-16116
> URL: https://issues.apache.org/jira/browse/HBASE-16116
> Project: HBase
>  Issue Type: Improvement
>Reporter: Konstantin Ryakhovskiy
>Priority: Trivial
>  Labels: beginner
> Attachments: HBASE-16116.patch
>
>
> .gitignore file contains pattern '*.iml' two times:
> {code}
> /.arc_jira_lib
> /.externalToolBuilders
> .project
> *.settings/
> .classpath
> /build
> /.idea/
> /logs
> *target/
> *.iml --- first appearance 
> *.orig
> *~
> hbase-*/test
> *.iws
> *.iml --- second appearance 
> *.ipr
> patchprocess/
> dependency-reduced-pom.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16116) .gitignore file contains '*.iml' two times

2016-06-26 Thread Konstantin Ryakhovskiy (JIRA)

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

Konstantin Ryakhovskiy updated HBASE-16116:
---
Status: Patch Available  (was: Open)

patch provided

> .gitignore file contains '*.iml' two times
> --
>
> Key: HBASE-16116
> URL: https://issues.apache.org/jira/browse/HBASE-16116
> Project: HBase
>  Issue Type: Improvement
>Reporter: Konstantin Ryakhovskiy
>Priority: Trivial
>  Labels: beginner
> Attachments: HBASE-16116.patch
>
>
> .gitignore file contains pattern '*.iml' two times:
> {code}
> /.arc_jira_lib
> /.externalToolBuilders
> .project
> *.settings/
> .classpath
> /build
> /.idea/
> /logs
> *target/
> *.iml --- first appearance 
> *.orig
> *~
> hbase-*/test
> *.iws
> *.iml --- second appearance 
> *.ipr
> patchprocess/
> dependency-reduced-pom.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Issue Comment Deleted] (HBASE-16116) .gitignore file contains '*.iml' two times

2016-06-26 Thread Konstantin Ryakhovskiy (JIRA)

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

Konstantin Ryakhovskiy updated HBASE-16116:
---
Comment: was deleted

(was: patch provided)

> .gitignore file contains '*.iml' two times
> --
>
> Key: HBASE-16116
> URL: https://issues.apache.org/jira/browse/HBASE-16116
> Project: HBase
>  Issue Type: Improvement
>Reporter: Konstantin Ryakhovskiy
>Priority: Trivial
>  Labels: beginner
> Attachments: HBASE-16116.patch
>
>
> .gitignore file contains pattern '*.iml' two times:
> {code}
> /.arc_jira_lib
> /.externalToolBuilders
> .project
> *.settings/
> .classpath
> /build
> /.idea/
> /logs
> *target/
> *.iml --- first appearance 
> *.orig
> *~
> hbase-*/test
> *.iws
> *.iml --- second appearance 
> *.ipr
> patchprocess/
> dependency-reduced-pom.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16116) .gitignore file contains '*.iml' two times

2016-06-26 Thread Konstantin Ryakhovskiy (JIRA)

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

Konstantin Ryakhovskiy updated HBASE-16116:
---
Attachment: HBASE-16116.patch

patch contains changes for the issue, redundant line is removed

> .gitignore file contains '*.iml' two times
> --
>
> Key: HBASE-16116
> URL: https://issues.apache.org/jira/browse/HBASE-16116
> Project: HBase
>  Issue Type: Improvement
>Reporter: Konstantin Ryakhovskiy
>Priority: Trivial
>  Labels: beginner
> Attachments: HBASE-16116.patch
>
>
> .gitignore file contains pattern '*.iml' two times:
> {code}
> /.arc_jira_lib
> /.externalToolBuilders
> .project
> *.settings/
> .classpath
> /build
> /.idea/
> /logs
> *target/
> *.iml --- first appearance 
> *.orig
> *~
> hbase-*/test
> *.iws
> *.iml --- second appearance 
> *.ipr
> patchprocess/
> dependency-reduced-pom.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai edited comment on HBASE-16071 at 6/26/16 6:32 PM:


  all cells (delete tx => delete specified timestamp)
-
| delete t2 |
-
| delete t1 |
-
|  put t2   |
-
|  put t1   |
-
|  put t0   |
-

case 1 : (raw scan) + (scan max version=2)
cells we get back:4
-
| delete t2 |
-
| delete t1 |
-
|  put t2   |
-
|  put t1   |
-

case 2 : (normal scan) + (scan max version=2)
cells we get back:1
-
|  put t0   |
-




was (Author: chia7712):
  all cells (delete tx => delete specified timestamp)
-  |
| delete t2 |  |
-  |
| delete t1 |  |
-  |
|  put t2   |  |
-  |
|  put t1   |  |
-  |
|  put t0   |  ▼
- order

case 1 : (raw scan) + (scan max version=2)
cells we get back:4
-
| delete t2 |
-
| delete t1 |
-
|  put t2   |
-
|  put t1   |
-

case 2 : (normal scan) + (scan max version=2)
cells we get back:1
-
|  put t0   |
-



> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16071-v1.patch, HBASE-16071-v2.patch, 
> HBASE-16071-v3.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16116) .gitignore file contains '*.iml' two times

2016-06-26 Thread Konstantin Ryakhovskiy (JIRA)

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

Konstantin Ryakhovskiy updated HBASE-16116:
---
Description: 
.gitignore file contains pattern '*.iml' two times:
{code}
/.arc_jira_lib
/.externalToolBuilders
.project
*.settings/
.classpath
/build
/.idea/
/logs
*target/
*.iml --- first appearance 
*.orig
*~
hbase-*/test
*.iws
*.iml --- second appearance 
*.ipr
patchprocess/
dependency-reduced-pom.xml
{code}

  was:
.gitignore file contains pattern '*.iml' two times:
{code}
/.arc_jira_lib
/.externalToolBuilders
.project
*.settings/
.classpath
/build
/.idea/
/logs
*target/
*.iml
*.orig
*~
hbase-*/test
*.iws
*.iml
*.ipr
patchprocess/
dependency-reduced-pom.xml
{code}


> .gitignore file contains '*.iml' two times
> --
>
> Key: HBASE-16116
> URL: https://issues.apache.org/jira/browse/HBASE-16116
> Project: HBase
>  Issue Type: Improvement
>Reporter: Konstantin Ryakhovskiy
>Priority: Trivial
>  Labels: beginner
>
> .gitignore file contains pattern '*.iml' two times:
> {code}
> /.arc_jira_lib
> /.externalToolBuilders
> .project
> *.settings/
> .classpath
> /build
> /.idea/
> /logs
> *target/
> *.iml --- first appearance 
> *.orig
> *~
> hbase-*/test
> *.iws
> *.iml --- second appearance 
> *.ipr
> patchprocess/
> dependency-reduced-pom.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16116) .gitignore file contains '*.iml' two times

2016-06-26 Thread Konstantin Ryakhovskiy (JIRA)

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

Konstantin Ryakhovskiy updated HBASE-16116:
---
Description: 
.gitignore file contains pattern '*.iml' two times:
{code}
/.arc_jira_lib
/.externalToolBuilders
.project
*.settings/
.classpath
/build
/.idea/
/logs
*target/
*.iml
*.orig
*~
hbase-*/test
*.iws
*.iml
*.ipr
patchprocess/
dependency-reduced-pom.xml
{code}

  was:.gitignore file contains pattern '*.iml' two times


> .gitignore file contains '*.iml' two times
> --
>
> Key: HBASE-16116
> URL: https://issues.apache.org/jira/browse/HBASE-16116
> Project: HBase
>  Issue Type: Improvement
>Reporter: Konstantin Ryakhovskiy
>Priority: Trivial
>  Labels: beginner
>
> .gitignore file contains pattern '*.iml' two times:
> {code}
> /.arc_jira_lib
> /.externalToolBuilders
> .project
> *.settings/
> .classpath
> /build
> /.idea/
> /logs
> *target/
> *.iml
> *.orig
> *~
> hbase-*/test
> *.iws
> *.iml
> *.ipr
> patchprocess/
> dependency-reduced-pom.xml
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai commented on HBASE-16071:
---

  all cells (delete tx => delete specified timestamp)
-  |
| delete t2 |  |
-  |
| delete t1 |  |
-  |
|  put t2   |  |
-  |
|  put t1   |  |
-  |
|  put t0   |  ▼
- order

case 1 : (raw scan) + (scan max version=2)
cells we get back:4
-
| delete t2 |
-
| delete t1 |
-
|  put t2   |
-
|  put t1   |
-

case 2 : (normal scan) + (scan max version=2)
cells we get back:1
-
|  put t0   |
-



> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16071-v1.patch, HBASE-16071-v2.patch, 
> HBASE-16071-v3.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (HBASE-16116) .gitignore file contains '*.iml' two times

2016-06-26 Thread Konstantin Ryakhovskiy (JIRA)
Konstantin Ryakhovskiy created HBASE-16116:
--

 Summary: .gitignore file contains '*.iml' two times
 Key: HBASE-16116
 URL: https://issues.apache.org/jira/browse/HBASE-16116
 Project: HBase
  Issue Type: Improvement
Reporter: Konstantin Ryakhovskiy
Priority: Trivial


.gitignore file contains pattern '*.iml' two times



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16069) Typo "trapsparently" in item 3 of chapter 87.2 of Reference Guide

2016-06-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-16069:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s 
{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
6s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 39s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 26s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
55s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
26m 34s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 31s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 25s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 112m 53s 
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
21s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 158m 20s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.client.TestSizeFailures |
|   | hadoop.hbase.client.replication.TestReplicationAdminWithClusters |
|   | hadoop.hbase.client.TestAdmin1 |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12813471/HBASE-16069-master-v0.patch
 |
| JIRA Issue | HBASE-16069 |
| Optional Tests |  asflicense  javac  javadoc  unit  |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP 
PREEMPT Wed Sep 3 21:56:12 UTC 2014 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 / fc4b8aa |
| Default Java | 1.7.0_80 |
| Multi-JDK versions |  /home/jenkins/tools/java/jdk1.8.0:1.8.0 
/home/jenkins/jenkins-slave/tools/hudson.model.JDK/JDK_1.7_latest_:1.7.0_80 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/2366/artifact/patchprocess/patch-unit-root.txt
 |
| unit test logs |  
https://builds.apache.org/job/PreCommit-HBASE-Build/2366/artifact/patchprocess/patch-unit-root.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/2366/testReport/ |
| modules | C: . U: . |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/2366/console |
| Powered by | Apache Yetus 0.2.1   http://yetus.apache.org |


This message was automatically generated.



> Typo "trapsparently" in item 3 of chapter 87.2 of Reference Guide
> -
>
> Key: HBASE-16069
> URL: https://issues.apache.org/jira/browse/HBASE-16069
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: li xiang
>Assignee: li xiang
>Priority: Minor
>  Labels: document
> Attachments: HBASE-16069-master-v0.patch
>
>
> In Chapter 87.2. Coprocessor Implementation Overview
> ...
> 3. Call the coprocessor from your client-side code. HBase handles the 
> coprocessor trapsparently.
> ...
> Correct "trapsparently" into "transparently"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-14007) Writing to table through MR should fail upfront if table does not exist/disabled

2016-06-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-14007:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 1s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 42s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 42s 
{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 with JDK v1.7.0_80 {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 
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
27m 9s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 105m 46s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
19s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 149m 13s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestAcidGuarantees |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12813402/HBASE-14007.master.001.patch
 |
| JIRA Issue | HBASE-14007 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux asf900.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP 
PREEMPT Wed Sep 3 21:56:12 UTC 2014 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 / fc4b8aa |
| Default Java | 1.7.0_80 |
| Multi-JDK versions |  /home/jenkins/tools/java/jdk1.8.0:1.8.0 
/home/jenkins/jenkins-slave/tools/hudson.model.JDK/JDK_1.7_latest_:1.7.0_80 |
| findbugs | v3.0.0 |
| 

[jira] [Commented] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread Anoop Sam John (JIRA)

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

Anoop Sam John commented on HBASE-16071:


When Scan is set with rawScan and we have 2 versions deleted and another non 
deleted version. So there are total 5 cells (2 DELETE type and 3 PUT type) out 
of which only one is undeleted.  How many cells we get back? (In normal scan 
case- no vis labels).Say scan maxVersions set to 2.

> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16071-v1.patch, HBASE-16071-v2.patch, 
> HBASE-16071-v3.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-16071:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s 
{color} | {color:green} master passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
53s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
56s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s 
{color} | {color:green} master passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} master passed with JDK v1.7.0_80 {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 43s 
{color} | {color:green} the patch passed with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 43s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s 
{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 
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
25m 56s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 8s 
{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 with JDK v1.8.0 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s 
{color} | {color:green} the patch passed with JDK v1.7.0_80 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 90m 38s 
{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
17s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 131m 45s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12813468/HBASE-16071-v3.patch |
| JIRA Issue | HBASE-16071 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP 
PREEMPT Wed Sep 3 21:56:12 UTC 2014 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 / fc4b8aa |
| Default Java | 1.7.0_80 |
| Multi-JDK versions |  /home/jenkins/tools/java/jdk1.8.0:1.8.0 
/home/jenkins/jenkins-slave/tools/hudson.model.JDK/JDK_1.7_latest_:1.7.0_80 |
| findbugs | v3.0.0 |
|  Test Results | 

[jira] [Updated] (HBASE-16069) Typo "trapsparently" in item 3 of chapter 87.2 of Reference Guide

2016-06-26 Thread li xiang (JIRA)

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

li xiang updated HBASE-16069:
-
Labels: document  (was: )
Status: Patch Available  (was: Open)

> Typo "trapsparently" in item 3 of chapter 87.2 of Reference Guide
> -
>
> Key: HBASE-16069
> URL: https://issues.apache.org/jira/browse/HBASE-16069
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: li xiang
>Assignee: li xiang
>Priority: Minor
>  Labels: document
> Attachments: HBASE-16069-master-v0.patch
>
>
> In Chapter 87.2. Coprocessor Implementation Overview
> ...
> 3. Call the coprocessor from your client-side code. HBase handles the 
> coprocessor trapsparently.
> ...
> Correct "trapsparently" into "transparently"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16069) Typo "trapsparently" in item 3 of chapter 87.2 of Reference Guide

2016-06-26 Thread li xiang (JIRA)

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

li xiang updated HBASE-16069:
-
Attachment: HBASE-16069-master-v0.patch

Updated patch v0

> Typo "trapsparently" in item 3 of chapter 87.2 of Reference Guide
> -
>
> Key: HBASE-16069
> URL: https://issues.apache.org/jira/browse/HBASE-16069
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: li xiang
>Assignee: li xiang
>Priority: Minor
> Attachments: HBASE-16069-master-v0.patch
>
>
> In Chapter 87.2. Coprocessor Implementation Overview
> ...
> 3. Call the coprocessor from your client-side code. HBase handles the 
> coprocessor trapsparently.
> ...
> Correct "trapsparently" into "transparently"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai updated HBASE-16071:
--
Attachment: HBASE-16071-v3.patch

> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16071-v1.patch, HBASE-16071-v2.patch, 
> HBASE-16071-v3.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai updated HBASE-16071:
--
Attachment: (was: HBASE-16017-v3.patch)

> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16071-v1.patch, HBASE-16071-v2.patch, 
> HBASE-16071-v3.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai updated HBASE-16071:
--
Status: Patch Available  (was: Open)

> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16071-v1.patch, HBASE-16071-v2.patch, 
> HBASE-16071-v3.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai updated HBASE-16071:
--
Attachment: HBASE-16017-v3.patch

fixs the whitespace

The TestFlushSnapshotFromClient, TestMobFlushSnapshotFromClient and TestHCM are 
passed locally.

> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16017-v3.patch, HBASE-16071-v1.patch, 
> HBASE-16071-v2.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16071) The VisibilityLabelFilter and AccessControlFilter should not count the "delete cell"

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai updated HBASE-16071:
--
Status: Open  (was: Patch Available)

> The VisibilityLabelFilter and AccessControlFilter should not count the 
> "delete cell"
> 
>
> Key: HBASE-16071
> URL: https://issues.apache.org/jira/browse/HBASE-16071
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: ChiaPing Tsai
>Assignee: ChiaPing Tsai
>Priority: Minor
> Fix For: 2.0.0, 1.3.0, 1.4.0
>
> Attachments: HBASE-16071-v1.patch, HBASE-16071-v2.patch
>
>
> The VisibilityLabelFilter will see and count the "delete cell" if the 
> scan.isRaw() returns true, so the (put) cell will be skipped if it has lower 
> version than "delete cell"
> The critical code is shown below:
> {code:title=VisibilityLabelFilter.java|borderStyle=solid}
>   public ReturnCode filterKeyValue(Cell cell) throws IOException {
> if (curFamily.getBytes() == null
> || !(CellUtil.matchingFamily(cell, curFamily.getBytes(), 
> curFamily.getOffset(),
> curFamily.getLength( {
>   curFamily.set(cell.getFamilyArray(), cell.getFamilyOffset(), 
> cell.getFamilyLength());
>   // For this family, all the columns can have max of 
> curFamilyMaxVersions versions. No need to
>   // consider the older versions for visibility label check.
>   // Ideally this should have been done at a lower layer by HBase (?)
>   curFamilyMaxVersions = cfVsMaxVersions.get(curFamily);
>   // Family is changed. Just unset curQualifier.
>   curQualifier.unset();
> }
> if (curQualifier.getBytes() == null
> || !(CellUtil.matchingQualifier(cell, curQualifier.getBytes(), 
> curQualifier.getOffset(),
> curQualifier.getLength( {
>   curQualifier.set(cell.getQualifierArray(), cell.getQualifierOffset(),
>   cell.getQualifierLength());
>   curQualMetVersions = 0;
> }
> curQualMetVersions++;
> if (curQualMetVersions > curFamilyMaxVersions) {
>   return ReturnCode.SKIP;
> }
> return this.expEvaluator.evaluate(cell) ? ReturnCode.INCLUDE : 
> ReturnCode.SKIP;
>   }
> {code}
> [VisibilityLabelFilter.java|https://github.com/apache/hbase/blob/d7a4499dfc8b3936a0eca867589fc2b23b597866/hbase-server/src/main/java/org/apache/hadoop/hbase/security/visibility/VisibilityLabelFilter.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (HBASE-16113) The raw scan with "zero" max versions should return empty result

2016-06-26 Thread ChiaPing Tsai (JIRA)

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

ChiaPing Tsai resolved HBASE-16113.
---
  Resolution: Not A Problem
Release Note: I misunderstood what the "max versions" meant

> The raw scan with "zero" max versions should return empty result
> 
>
> Key: HBASE-16113
> URL: https://issues.apache.org/jira/browse/HBASE-16113
> Project: HBase
>  Issue Type: Bug
>Reporter: ChiaPing Tsai
>Priority: Trivial
>
> Step 1: put a cell
> Step 2: delete the cell
> Step 3: Scan#setRaw(true).setMaxVersions(0)
> Step 4: Result result = table.getScanner(scan).next()
> Step 5: The result will contain a Cell of DELETE type
> Is it a correct result ? The critical code is shown below:
> {code:title=ScanWildcardColumnTracker.java|borderStyle=solid}
> // May be we should check the verion first
>   private MatchCode checkVersion(byte type, long timestamp) {
> if (!CellUtil.isDelete(type)) {
>   currentCount++;
> }
> if (currentCount > maxVersions) {
>   return ScanQueryMatcher.MatchCode.SEEK_NEXT_COL; // skip to next col
> }
> // keep the KV if required by minversions or it is not expired, yet
> if (currentCount <= minVersions || !isExpired(timestamp)) {
>   setTSAndType(timestamp, type);
>   return ScanQueryMatcher.MatchCode.INCLUDE;
> } else {
>   return MatchCode.SEEK_NEXT_COL;
> }
>   }
> {code}
> Comments?
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (HBASE-16074) ITBLL fails, reports lost big or tine families

2016-06-26 Thread Mikhail Antonov (JIRA)

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

Mikhail Antonov updated HBASE-16074:

Attachment: changes_to_stress_ITBLL.patch

I was able to get the errors running ITBLL in minicluster from the IDE with the 
following ad-hoc patch, FYI.

> ITBLL fails, reports lost big or tine families
> --
>
> Key: HBASE-16074
> URL: https://issues.apache.org/jira/browse/HBASE-16074
> Project: HBase
>  Issue Type: Bug
>  Components: integration tests
>Affects Versions: 1.3.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
>Priority: Blocker
> Fix For: 1.3.0
>
> Attachments: changes_to_stress_ITBLL.patch
>
>
> Underlying MR jobs succeed but I'm seeing the following in the logs (mid-size 
> distributed test cluster):
> ERROR test.IntegrationTestBigLinkedList$Verify: Found nodes which lost big or 
> tiny families, count=164
> I do not know exactly yet whether it's a bug, a test issue or env setup 
> issue, but need figure it out. Opening this to raise awareness and see if 
> someone saw that recently.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (HBASE-16115) Missing security context in RegionObserver coprocessor when a compaction is triggered through the UI

2016-06-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell commented on HBASE-16115:


I'm glad you guys figured out the interesting detail was use of the UI, because 
I was still at a loss after staring at the code for a while yesterday 
afternoon. 

It's plausable the contexts set up by Jetty when serving UI requests might not 
be logged in (we're not using authentication filters which would do that, 
albeit with the client credentials), and if so this was bound to cause problems 
sooner or later. We see it here because for the first time something is trying 
to issue a remote RPC when servicing the compaction request. 

> Missing security context in RegionObserver coprocessor when a compaction is 
> triggered through the UI
> 
>
> Key: HBASE-16115
> URL: https://issues.apache.org/jira/browse/HBASE-16115
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 0.98.20
>Reporter: Lars Hofhansl
>
> We ran into an interesting phenomenon which can easily render a cluster 
> unusable.
> We loaded some tests data into a test table and forced a manual compaction 
> through the UI. We have some compaction hooks implemented in a region 
> observer, which writes back to another HBase table when the compaction 
> finishes. We noticed that this coprocessor is not setup correctly, it seems 
> the security context is missing.
> The interesting part is that this _only_ happens when the compaction is 
> triggere through the UI. Automatic compactions (major or minor) or when 
> triggered via the HBase shell (folling a kinit) work fine. Only the 
> UI-triggered compactions cause this issues and lead to essentially 
> neverending compactions, immovable regions, etc.
> Not sure what exactly the issue is, but I wanted to make sure I capture this.
> [~apurtell], [~ghelmling], FYI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)