date:20140401


[ 
https://issues.apache.org/jira/browse/HBASE-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956147#comment-13956147
 ] 

ramkrishna.s.vasudevan commented on HBASE-10855:


For me too it passes locally changing the version to V3.
But just seeing the test case one guess would be that because we use V3 once we 
flush we would atleast write the tag length (of type short).
Here we only make two puts for two diff families.  The size of the HFile may be 
a bigger by 2 bytes now. Will that be a reason here?


 Enable hfilev3 by default
 -

 Key: HBASE-10855
 URL: https://issues.apache.org/jira/browse/HBASE-10855
 Project: HBase
  Issue Type: Sub-task
  Components: HFile
Reporter: stack
Assignee: stack
 Fix For: 0.99.0

 Attachments: 10855.txt, 10855.txt, 10855.txt, 10855.txt


 Distributed log replay needs this.  Should be on by default in 1.0/0.99.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10855) Enable hfilev3 by default

2014-04-01 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956150#comment-13956150
 ] 

stack commented on HBASE-10855:
---

Let me look at it [~ram_krish]  I have a little rig here so can dig.  Will bug 
you fellows if can't figure it.  It seems like a good test but a little fragile 
anyways 

 Enable hfilev3 by default
 -

 Key: HBASE-10855
 URL: https://issues.apache.org/jira/browse/HBASE-10855
 Project: HBase
  Issue Type: Sub-task
  Components: HFile
Reporter: stack
Assignee: stack
 Fix For: 0.99.0

 Attachments: 10855.txt, 10855.txt, 10855.txt, 10855.txt


 Distributed log replay needs this.  Should be on by default in 1.0/0.99.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10867) TestRegionPlacement#testRegionPlacement occasionally fails


[ 
https://issues.apache.org/jira/browse/HBASE-10867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956153#comment-13956153
 ] 

Hudson commented on HBASE-10867:


FAILURE: Integrated in HBase-TRUNK #5053 (See 
[https://builds.apache.org/job/HBase-TRUNK/5053/])
HBASE-10867 TestRegionPlacement#testRegionPlacement occasionally fails (tedyu: 
rev 1583515)
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/TestRegionPlacement.java


 TestRegionPlacement#testRegionPlacement occasionally fails
 --

 Key: HBASE-10867
 URL: https://issues.apache.org/jira/browse/HBASE-10867
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Fix For: 0.99.0

 Attachments: 10867-v1.txt, 10867-v2.txt


 From 
 https://builds.apache.org/job/HBase-TRUNK/5047/testReport/org.apache.hadoop.hbase.master/TestRegionPlacement/testRegionPlacement/
  :
 {code}
 java.lang.ArrayIndexOutOfBoundsException: 10
   at 
 java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:368)
   at 
 java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:377)
   at 
 org.apache.hadoop.hbase.LocalHBaseCluster.getRegionServer(LocalHBaseCluster.java:224)
   at 
 org.apache.hadoop.hbase.MiniHBaseCluster.getRegionServer(MiniHBaseCluster.java:609)
   at 
 org.apache.hadoop.hbase.master.TestRegionPlacement.killRandomServerAndVerifyAssignment(TestRegionPlacement.java:303)
   at 
 org.apache.hadoop.hbase.master.TestRegionPlacement.testRegionPlacement(TestRegionPlacement.java:270)
 {code}
 In the setup:
 {code}
 TEST_UTIL.startMiniCluster(SLAVES);
 {code}
 where SLAVES is 10.
 So when 10 was used in 
 TEST_UTIL.getHBaseCluster().getRegionServer(killIndex), we would get 
 ArrayIndexOutOfBoundsException.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10848) Filter SingleColumnValueFilter combined with NullComparator does not work


[ 
https://issues.apache.org/jira/browse/HBASE-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956152#comment-13956152
 ] 

Hudson commented on HBASE-10848:


FAILURE: Integrated in HBase-TRUNK #5053 (See 
[https://builds.apache.org/job/HBase-TRUNK/5053/])
HBASE-10848 Filter SingleColumnValueFilter combined with NullComparator does 
not work (Fabien) (tedyu: rev 1583511)
* 
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/NullComparator.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestNullComparator.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestSingleColumnValueFilter.java


 Filter SingleColumnValueFilter combined with NullComparator does not work
 -

 Key: HBASE-10848
 URL: https://issues.apache.org/jira/browse/HBASE-10848
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 0.96.1.1
Reporter: Fabien Le Gallo
Assignee: Fabien Le Gallo
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10848.patch, HBASE_10848-v2.patch, 
 HBASE_10848-v3.patch, HBASE_10848-v4.patch, HBaseRegression.java, 
 TestScanWithNullComparable.java


 I want to filter out from the scan the rows that does not have a specific 
 column qualifier. For this purpose I use the filter SingleColumnValueFilter 
 combined with the NullComparator.
 But every time I use this in a scan, I get the following exception:
 {code}
 java.lang.RuntimeException: org.apache.hadoop.hbase.DoNotRetryIOException: 
 Failed after retry of OutOfOrderScannerNextException: was there a rpc timeout?
 at 
 org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:47)
 at 
 com.xxx.xxx.test.HBaseRegression.nullComparator(HBaseRegression.java:92)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
 at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
 at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
 Caused by: org.apache.hadoop.hbase.DoNotRetryIOException: Failed after retry 
 of OutOfOrderScannerNextException: was there a rpc timeout?
 at 
 org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:391)
 at 
 org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:44)
 ... 25 more
 Caused by: org.apache.hadoop.hbase.exceptions.OutOfOrderScannerNextException: 
 org.apache.hadoop.hbase.exceptions.OutOfOrderScannerNextException: Expected 
 nextCallSeq: 1 But the nextCallSeq got from client: 0; request=scanner_id: 
 7998309028985532303 number_of_rows: 100 close_scanner: false next_call_seq: 0
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3011)
 at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26929)
 at

[jira] [Commented] (HBASE-10866) Decouple HLogSplitterHandler from ZooKeeper

2014-04-01 Thread Mikhail Antonov (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956155#comment-13956155
 ] 

Mikhail Antonov commented on HBASE-10866:
-

[~ lhofhansl] thanks for feedback!

Yeah, totally understand this abstraction effort needs to be finished 
everywhere (and also the fact that it's quite a bit of work, affecting  many 
places in the codebase). The piecemeal approach would provide for easier 
review/feedbacks of patches to ensure they're in line with the goal (as 
[~stack] and [~cos] noted), and for better work structuring and parallelization.

 Decouple HLogSplitterHandler from ZooKeeper
 ---

 Key: HBASE-10866
 URL: https://issues.apache.org/jira/browse/HBASE-10866
 Project: HBase
  Issue Type: Improvement
  Components: regionserver, Zookeeper
Reporter: Mikhail Antonov
 Attachments: HBASE-10866.patch, HBASE-10866.patch, HBASE-10866.patch, 
 HBASE-10866.patch, HBaseConsensus.pdf


 As some sort of follow-up or initial step towards HBASE-10296...
 Whatever consensus algorithm/library may be the chosen, perhaps on of first 
 practical steps towards this goal would be to better abstract ZK-related API 
 and details, which are now throughout the codebase (mostly leaked throuth 
 ZkUtil, ZooKeeperWatcher and listeners).
 I'd like to propose a series of patches to help better abstract out zookeeper 
 (and then help develop consensus APIs). 
 Here is first version of  patch for initial review (then I'm planning to work 
 on another handlers in regionserver, and then perhaps start working on 
 abstracting listeners).



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10881) Support reverse scan in thrift2


[ 
https://issues.apache.org/jira/browse/HBASE-10881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956159#comment-13956159
 ] 

Hadoop QA commented on HBASE-10881:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12637993/HBASE-10881-trunk-v1.diff
  against trunk revision .
  ATTACHMENT ID: 12637993

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+  private static final org.apache.thrift.protocol.TField 
REVERSED_FIELD_DESC = new org.apache.thrift.protocol.TField(reversed, 
org.apache.thrift.protocol.TType.BOOL, (short)11);
+  private _Fields optionals[] = 
{_Fields.START_ROW,_Fields.STOP_ROW,_Fields.COLUMNS,_Fields.CACHING,_Fields.MAX_VERSIONS,_Fields.TIME_RANGE,_Fields.FILTER_STRING,_Fields.BATCH_SIZE,_Fields.ATTRIBUTES,_Fields.AUTHORIZATIONS,_Fields.REVERSED};
+tmpMap.put(_Fields.REVERSED, new 
org.apache.thrift.meta_data.FieldMetaData(reversed, 
org.apache.thrift.TFieldRequirementType.OPTIONAL, 
+  org.apache.thrift.protocol.TList _list117 = new 
org.apache.thrift.protocol.TList(org.apache.thrift.protocol.TType.STRUCT, 
iprot.readI32());
+  org.apache.thrift.protocol.TMap _map120 = new 
org.apache.thrift.protocol.TMap(org.apache.thrift.protocol.TType.STRING, 
org.apache.thrift.protocol.TType.STRING, iprot.readI32());

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s):   
at 
org.apache.hadoop.hbase.mapreduce.TestTableMapReduceBase.testMultiRegionTable(TestTableMapReduceBase.java:96)

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9152//console

This message is automatically generated.

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Attachments: HBASE-10881-trunk-v1.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10848) Filter SingleColumnValueFilter combined with NullComparator does not work


[ 
https://issues.apache.org/jira/browse/HBASE-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956164#comment-13956164
 ] 

Hudson commented on HBASE-10848:


SUCCESS: Integrated in HBase-0.98 #258 (See 
[https://builds.apache.org/job/HBase-0.98/258/])
HBASE-10848 Filter SingleColumnValueFilter combined with NullComparator does 
not work (Fabien) (tedyu: rev 1583510)
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/NullComparator.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestNullComparator.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestSingleColumnValueFilter.java


 Filter SingleColumnValueFilter combined with NullComparator does not work
 -

 Key: HBASE-10848
 URL: https://issues.apache.org/jira/browse/HBASE-10848
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 0.96.1.1
Reporter: Fabien Le Gallo
Assignee: Fabien Le Gallo
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10848.patch, HBASE_10848-v2.patch, 
 HBASE_10848-v3.patch, HBASE_10848-v4.patch, HBaseRegression.java, 
 TestScanWithNullComparable.java


 I want to filter out from the scan the rows that does not have a specific 
 column qualifier. For this purpose I use the filter SingleColumnValueFilter 
 combined with the NullComparator.
 But every time I use this in a scan, I get the following exception:
 {code}
 java.lang.RuntimeException: org.apache.hadoop.hbase.DoNotRetryIOException: 
 Failed after retry of OutOfOrderScannerNextException: was there a rpc timeout?
 at 
 org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:47)
 at 
 com.xxx.xxx.test.HBaseRegression.nullComparator(HBaseRegression.java:92)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
 at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
 at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
 Caused by: org.apache.hadoop.hbase.DoNotRetryIOException: Failed after retry 
 of OutOfOrderScannerNextException: was there a rpc timeout?
 at 
 org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:391)
 at 
 org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:44)
 ... 25 more
 Caused by: org.apache.hadoop.hbase.exceptions.OutOfOrderScannerNextException: 
 org.apache.hadoop.hbase.exceptions.OutOfOrderScannerNextException: Expected 
 nextCallSeq: 1 But the nextCallSeq got from client: 0; request=scanner_id: 
 7998309028985532303 number_of_rows: 100 close_scanner: false next_call_seq: 0
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3011)
 at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26929)
 at

[jira] [Commented] (HBASE-10848) Filter SingleColumnValueFilter combined with NullComparator does not work


[ 
https://issues.apache.org/jira/browse/HBASE-10848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956165#comment-13956165
 ] 

Hudson commented on HBASE-10848:


FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #242 (See 
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/242/])
HBASE-10848 Filter SingleColumnValueFilter combined with NullComparator does 
not work (Fabien) (tedyu: rev 1583510)
* 
/hbase/branches/0.98/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/NullComparator.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestNullComparator.java
* 
/hbase/branches/0.98/hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestSingleColumnValueFilter.java


 Filter SingleColumnValueFilter combined with NullComparator does not work
 -

 Key: HBASE-10848
 URL: https://issues.apache.org/jira/browse/HBASE-10848
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 0.96.1.1
Reporter: Fabien Le Gallo
Assignee: Fabien Le Gallo
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10848.patch, HBASE_10848-v2.patch, 
 HBASE_10848-v3.patch, HBASE_10848-v4.patch, HBaseRegression.java, 
 TestScanWithNullComparable.java


 I want to filter out from the scan the rows that does not have a specific 
 column qualifier. For this purpose I use the filter SingleColumnValueFilter 
 combined with the NullComparator.
 But every time I use this in a scan, I get the following exception:
 {code}
 java.lang.RuntimeException: org.apache.hadoop.hbase.DoNotRetryIOException: 
 Failed after retry of OutOfOrderScannerNextException: was there a rpc timeout?
 at 
 org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:47)
 at 
 com.xxx.xxx.test.HBaseRegression.nullComparator(HBaseRegression.java:92)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
 at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
 at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
 at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
 at 
 org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
 at 
 org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
 at 
 org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
 Caused by: org.apache.hadoop.hbase.DoNotRetryIOException: Failed after retry 
 of OutOfOrderScannerNextException: was there a rpc timeout?
 at 
 org.apache.hadoop.hbase.client.ClientScanner.next(ClientScanner.java:391)
 at 
 org.apache.hadoop.hbase.client.AbstractClientScanner$1.hasNext(AbstractClientScanner.java:44)
 ... 25 more
 Caused by: org.apache.hadoop.hbase.exceptions.OutOfOrderScannerNextException: 
 org.apache.hadoop.hbase.exceptions.OutOfOrderScannerNextException: Expected 
 nextCallSeq: 1 But the nextCallSeq got from client: 0; request=scanner_id: 
 7998309028985532303 number_of_rows: 100 close_scanner: false next_call_seq: 0
 at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3011)
 at

[jira] [Commented] (HBASE-10531) Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo


[ 
https://issues.apache.org/jira/browse/HBASE-10531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956168#comment-13956168
 ] 

ramkrishna.s.vasudevan commented on HBASE-10531:


The test failure 
{code}
org.apache.hadoop.hbase.master.TestMasterFailover.testSimpleMasterFailover
org.apache.hadoop.hbase.regionserver.TestHRegionBusyWait.testBatchPut
{code}
did not occur locally in my testruns and also in hadoopQA run.  Also the 
subsequent runs does not have this failure. JFYI.

 Revisit how the key byte[] is passed to HFileScanner.seekTo and reseekTo
 

 Key: HBASE-10531
 URL: https://issues.apache.org/jira/browse/HBASE-10531
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 0.99.0

 Attachments: HBASE-10531.patch, HBASE-10531_1.patch, 
 HBASE-10531_12.patch, HBASE-10531_13.patch, HBASE-10531_13.patch, 
 HBASE-10531_2.patch, HBASE-10531_3.patch, HBASE-10531_4.patch, 
 HBASE-10531_5.patch, HBASE-10531_6.patch, HBASE-10531_7.patch, 
 HBASE-10531_8.patch, HBASE-10531_9.patch


 Currently the byte[] key passed to HFileScanner.seekTo and 
 HFileScanner.reseekTo, is a combination of row, cf, qual, type and ts.  And 
 the caller forms this by using kv.getBuffer, which is actually deprecated.  
 So see how this can be achieved considering kv.getBuffer is removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10878) Operator | for visibility label doesn't work


[ 
https://issues.apache.org/jira/browse/HBASE-10878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956181#comment-13956181
 ] 

Andrew Purtell commented on HBASE-10878:


Thanks for trying this stuff out [~tedyu]. I filed HBASE-10883 as follow up to 
this issue.

 Operator | for visibility label doesn't work
 

 Key: HBASE-10878
 URL: https://issues.apache.org/jira/browse/HBASE-10878
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu

 I used setup similar to that from HBASE-10863, with fix for HBASE-10863 :
 {code}
 hbase(main):003:0 scan 'hbase:labels'
 ROW  COLUMN+CELL
  \x00\x00\x00\x01column=f:\x00, 
 timestamp=1395944796030, value=system
  \x00\x00\x00\x01column=f:hbase, 
 timestamp=1395944796030, value=
  \x00\x00\x00\x02column=f:\x00, 
 timestamp=1395951045442, value=TOP_SECRET
  \x00\x00\x00\x02column=f:hrt_qa, 
 timestamp=1395951229682, value=
  \x00\x00\x00\x02column=f:hrt_qa1, 
 timestamp=1395951270297, value=
  \x00\x00\x00\x02column=f:mapred, 
 timestamp=1395958442326, value=
  \x00\x00\x00\x03column=f:\x00, 
 timestamp=1395952069731, value=TOP_TOP_SECRET
  \x00\x00\x00\x03column=f:mapred, 
 timestamp=1395956032141, value=
  \x00\x00\x00\x04column=f:\x00, 
 timestamp=1395971516605, value=A
  \x00\x00\x00\x04column=f:oozie, 
 timestamp=1395971647859, value=
  \x00\x00\x00\x05column=f:\x00, 
 timestamp=1395971520327, value=B
 5 row(s) in 0.0580 seconds
 {code}
 I did the following as user oozie using hbase shell:
 {code}
 hbase(main):001:0 scan 'tb', { AUTHORIZATIONS = ['A']}
 ROW  COLUMN+CELL
  row column=f1:q, 
 timestamp=1395971660859, value=v1
  row2column=f1:q, 
 timestamp=1395972271343, value=v2
  row3column=f1:q, 
 timestamp=1396067477702, value=v3
 3 row(s) in 0.2050 seconds
 hbase(main):002:0 scan 'tb', { AUTHORIZATIONS = ['A|B']}
 ROW  COLUMN+CELL
  row2column=f1:q, 
 timestamp=1395972271343, value=v2
 1 row(s) in 0.0150 seconds
 hbase(main):003:0 scan 'tb', { AUTHORIZATIONS = ['B|A']}
 ROW  COLUMN+CELL
  row2column=f1:q, 
 timestamp=1395972271343, value=v2
 1 row(s) in 0.0260 seconds
 {code}
 Rows 'row' and 'row3' were inserted with label 'A'.
 Row 'row2' was inserted without label.
 Row 'row1' was inserted with label 'B'.
 I would expect row1 to also be returned.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (HBASE-10883) Restrict the universe of labels and authorizations to [A-Za-z0-9\_][A-Za-z0-9\_\-]*

Andrew Purtell created HBASE-10883:
--

 Summary: Restrict the universe of labels and authorizations to 
[A-Za-z0-9\_][A-Za-z0-9\_\-]*
 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2


Currently we allow any string as visibility label or request authorization. 
However as seen on HBASE-10878, we accept for authorizations strings that would 
not work if provided as labels in visibility expressions. We should throw an 
exception at least in cases where someone tries to define or use a label or 
authorization including visibility expression operators '', '|', '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10883) Restrict the universe of labels and authorizations to [A-Za-z0-9\_][A-Za-z0-9\_\-]*


[ 
https://issues.apache.org/jira/browse/HBASE-10883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956184#comment-13956184
 ] 

Andrew Purtell commented on HBASE-10883:


I think we should use the common pattern for identifiers in various programming 
languages, [A-Za-z\_][A-Za-z0-9\_\-]*

 Restrict the universe of labels and authorizations to 
 [A-Za-z0-9\_][A-Za-z0-9\_\-]*
 ---

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10883) Restrict the universe of labels and authorizations


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

Andrew Purtell updated HBASE-10883:
---

Summary: Restrict the universe of labels and authorizations  (was: Restrict 
the universe of labels and authorizations to [A-Za-z0-9\_][A-Za-z0-9\_\-]*)

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (HBASE-10884) [REST] Do not disable block caching when scanning

Andrew Purtell created HBASE-10884:
--

 Summary: [REST] Do not disable block caching when scanning
 Key: HBASE-10884
 URL: https://issues.apache.org/jira/browse/HBASE-10884
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.94.18, 0.96.1.1, 0.98.1
Reporter: Andrew Purtell


The REST gateway pessimistically disables block caching when issuing Scans to 
the cluster, using Scan#setCacheBlocks(false) in ScannerResultGenerator. It 
does not do this when issuing Gets on behalf of HTTP clients in 
RowResultGenerator. This is an old idea now, the reasons for doing so lost 
sometime back in the era when HBase walked the earth with dinosaurs ( 0.20). 
We probably should not be penalizing REST scans in this way. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (HBASE-10884) [REST] Do not disable block caching when scanning


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

Andrew Purtell reassigned HBASE-10884:
--

Assignee: Andrew Purtell

 [REST] Do not disable block caching when scanning
 -

 Key: HBASE-10884
 URL: https://issues.apache.org/jira/browse/HBASE-10884
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1, 0.96.1.1, 0.94.18
Reporter: Andrew Purtell
Assignee: Andrew Purtell

 The REST gateway pessimistically disables block caching when issuing Scans to 
 the cluster, using Scan#setCacheBlocks(false) in ScannerResultGenerator. It 
 does not do this when issuing Gets on behalf of HTTP clients in 
 RowResultGenerator. This is an old idea now, the reasons for doing so lost 
 sometime back in the era when HBase walked the earth with dinosaurs ( 0.20). 
 We probably should not be penalizing REST scans in this way. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10879) user_permission shell command on namespace doesn't work


[ 
https://issues.apache.org/jira/browse/HBASE-10879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956199#comment-13956199
 ] 

Andrew Purtell commented on HBASE-10879:


+1 for trunk and 0.98

Ping [~stack] - should go into 0.96 too, another namespace nit

 user_permission shell command on namespace doesn't work
 ---

 Key: HBASE-10879
 URL: https://issues.apache.org/jira/browse/HBASE-10879
 Project: HBase
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
 Attachments: 10879-v1.txt, 10879-v2.txt


 Currently user_permission command on namespace, e.g.
 {code}
 user_permission '@ns'
 {code}
 would result in the following exception:
 {code}
 Exception `NameError' at /usr/lib/hbase/lib/ruby/hbase/security.rb:170 - no 
 method 'getUserPermissions' for arguments 
 (org.apache.hadoop.hbase.protobuf.generated.  
 AccessControlProtos.AccessControlService.BlockingStub,org.jruby.java.proxies.ArrayJavaProxy)
  on Java::OrgApacheHadoopHbaseProtobuf::ProtobufUtil
 ERROR: no method 'getUserPermissions' for arguments 
 (org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.AccessControlService.BlockingStub,org.jruby.java.
proxies.ArrayJavaProxy) on 
 Java::OrgApacheHadoopHbaseProtobuf::ProtobufUtil
 Backtrace: /usr/lib/hbase/lib/ruby/hbase/security.rb:170:in `user_permission'
/usr/lib/hbase/lib/ruby/shell/commands/user_permission.rb:39:in 
 `command'
org/jruby/RubyKernel.java:2109:in `send'
/usr/lib/hbase/lib/ruby/shell/commands.rb:34:in `command_safe'
/usr/lib/hbase/lib/ruby/shell/commands.rb:91:in 
 `translate_hbase_exceptions'
/usr/lib/hbase/lib/ruby/shell/commands.rb:34:in `command_safe'
/usr/lib/hbase/lib/ruby/shell.rb:127:in `internal_command'
/usr/lib/hbase/lib/ruby/shell.rb:119:in `command'
(eval):2:in `user_permission'
(hbase):1:in `evaluate'
org/jruby/RubyKernel.java:1112:in `eval'
 {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (HBASE-10885) Support visibility expressions on Deletes

Andrew Purtell created HBASE-10885:
--

 Summary: Support visibility expressions on Deletes
 Key: HBASE-10885
 URL: https://issues.apache.org/jira/browse/HBASE-10885
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2


Accumulo can specify visibility expressions for delete markers. During 
compaction the cells covered by the tombstone are determined in part by 
matching the visibility expression. This is useful for the use case of data set 
coalescing, where entries from multiple data sets carrying different labels are 
combined into one common large table. Later, a subset of entries can be 
conveniently removed using visibility expressions.

Currently doing the same in HBase would only be possible with a custom 
coprocessor. Otherwise, a Delete will affect all cells covered by the tombstone 
regardless if they are visible to the user issuing the delete or not. This is 
correct behavior in that no data spill is possible, but certainly could be 
surprising, and is only meant to be transitional. We decided not to support 
visibility expressions on Deletes to control the complexity of the initial 
implementation.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10885) Support visibility expressions on Deletes

[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956211#comment-13956211
]

Andrew Purtell commented on HBASE-10885:

How we handle deletes in the AccessController is to only allow the delete if it
has covering permission. By that I mean CF ACLs and any ACLs in cells that
would be covered by the tombstone not already covered by a tombstone must grant
the subject access. If any do not, the delete is denied. We run an internal
RegionScanner to enumerate the cells that would be affected by the operation.

One way to do this for the VisibilityController is we could similarly run an
internal RegionScanner with the parameters of the submitted Delete op, filter
cells by effective visibility, and issue deletes scoped only to those cells
visible to the subject. This would be easier than trying to hook compaction
scanners and evaluating visibility expression tags there, because we will have
the effective label set for the user in the RPC context, not at compaction
time.

Support visibility expressions on Deletes
-

Key: HBASE-10885
URL: https://issues.apache.org/jira/browse/HBASE-10885
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

Accumulo can specify visibility expressions for delete markers. During
compaction the cells covered by the tombstone are determined in part by
matching the visibility expression. This is useful for the use case of data
set coalescing, where entries from multiple data sets carrying different
labels are combined into one common large table. Later, a subset of entries
can be conveniently removed using visibility expressions.
Currently doing the same in HBase would only be possible with a custom
coprocessor. Otherwise, a Delete will affect all cells covered by the
tombstone regardless if they are visible to the user issuing the delete or
not. This is correct behavior in that no data spill is possible, but
certainly could be surprising, and is only meant to be transitional. We
decided not to support visibility expressions on Deletes to control the
complexity of the initial implementation.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10881) Support reverse scan in thrift2


[ 
https://issues.apache.org/jira/browse/HBASE-10881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956248#comment-13956248
 ] 

Liang Xie commented on HBASE-10881:
---

[~tedyu] [~ram_krish] seems still had a complain even HBASE-10824 committed. 
mind opening a new jira to track it?

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Attachments: HBASE-10881-trunk-v1.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10881) Support reverse scan in thrift2


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

Liang Xie updated HBASE-10881:
--

Component/s: Thrift

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10881-trunk-v1.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10881) Support reverse scan in thrift2


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

Liang Xie updated HBASE-10881:
--

Fix Version/s: 0.99.0

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10881-trunk-v1.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10881) Support reverse scan in thrift2


[ 
https://issues.apache.org/jira/browse/HBASE-10881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956249#comment-13956249
 ] 

Liang Xie commented on HBASE-10881:
---

+1 for attached patch

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10881-trunk-v1.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10881) Support reverse scan in thrift2


[ 
https://issues.apache.org/jira/browse/HBASE-10881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956252#comment-13956252
 ] 

ramkrishna.s.vasudevan commented on HBASE-10881:


bq. mind opening a new jira to track it?
Okie.  
We might have to include
{code}
hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift2/generated
{code}
package also.

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10881-trunk-v1.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (HBASE-10886) add htrace-zipkin to the runtime dependencies again

2014-04-01 Thread Masatake Iwasaki (JIRA)

Masatake Iwasaki created HBASE-10886:


 Summary: add htrace-zipkin to the runtime dependencies again
 Key: HBASE-10886
 URL: https://issues.apache.org/jira/browse/HBASE-10886
 Project: HBase
  Issue Type: Improvement
Reporter: Masatake Iwasaki
Assignee: Masatake Iwasaki
Priority: Minor


Once htrace-zipkin was removed from depencencies in HBASE-9700. Because all of 
the depencencies of htrace-zipkin is bundled with HBase now, it is good to add 
it for the ease of use.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10886) add htrace-zipkin to the runtime dependencies again

2014-04-01 Thread Masatake Iwasaki (JIRA)


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

Masatake Iwasaki updated HBASE-10886:
-

Attachment: HBASE-10886-0.patch

 add htrace-zipkin to the runtime dependencies again
 ---

 Key: HBASE-10886
 URL: https://issues.apache.org/jira/browse/HBASE-10886
 Project: HBase
  Issue Type: Improvement
Reporter: Masatake Iwasaki
Assignee: Masatake Iwasaki
Priority: Minor
 Attachments: HBASE-10886-0.patch


 Once htrace-zipkin was removed from depencencies in HBASE-9700. Because all 
 of the depencencies of htrace-zipkin is bundled with HBase now, it is good to 
 add it for the ease of use.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10886) add htrace-zipkin to the runtime dependencies again

2014-04-01 Thread Masatake Iwasaki (JIRA)


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

Masatake Iwasaki updated HBASE-10886:
-

Status: Patch Available  (was: Open)

 add htrace-zipkin to the runtime dependencies again
 ---

 Key: HBASE-10886
 URL: https://issues.apache.org/jira/browse/HBASE-10886
 Project: HBase
  Issue Type: Improvement
Reporter: Masatake Iwasaki
Assignee: Masatake Iwasaki
Priority: Minor
 Attachments: HBASE-10886-0.patch


 Once htrace-zipkin was removed from depencencies in HBASE-9700. Because all 
 of the depencencies of htrace-zipkin is bundled with HBase now, it is good to 
 add it for the ease of use.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10881) Support reverse scan in thrift2


[ 
https://issues.apache.org/jira/browse/HBASE-10881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956263#comment-13956263
 ] 

Liang Xie commented on HBASE-10881:
---

[~liushaohui], just realized the old thrift(maybe we can say thrift1?) also 
doesn't support reverse scan in current codebase, could you enhance it if get 
any change? thks!

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10881-trunk-v1.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10883) Restrict the universe of labels and authorizations


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

ramkrishna.s.vasudevan updated HBASE-10883:
---

Attachment: HBASE-10883.patch

Patch for trunk.  Should apply on 0.98 also.
Tested with shell also.  Throws exception if any special characters are used.

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10883) Restrict the universe of labels and authorizations


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

ramkrishna.s.vasudevan updated HBASE-10883:
---

Status: Patch Available  (was: Open)

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (HBASE-7781) Update security unit tests to use a KDC if available


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

ramkrishna.s.vasudevan reassigned HBASE-7781:
-

Assignee: (was: ramkrishna.s.vasudevan)

 Update security unit tests to use a KDC if available
 

 Key: HBASE-7781
 URL: https://issues.apache.org/jira/browse/HBASE-7781
 Project: HBase
  Issue Type: Test
  Components: security, test
Reporter: Gary Helmling
Priority: Blocker

 We currently have large holes in the test coverage of HBase with security 
 enabled.  Two recent examples of bugs which really should have been caught 
 with testing are HBASE-7771 and HBASE-7772.  The long standing problem with 
 testing with security enabled has been the requirement for supporting 
 kerberos infrastructure.
 We need to close this gap and provide some automated testing with security 
 enabled, if necessary standing up and provisioning a temporary KDC as an 
 option for running integration tests, see HADOOP-8078 and HADOOP-9004 where a 
 similar approach was taken.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10830) Integration test MR jobs attempt to load htrace jars from the wrong location


[ 
https://issues.apache.org/jira/browse/HBASE-10830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956292#comment-13956292
 ] 

Andrew Purtell commented on HBASE-10830:


+1 thanks [~ndimiduk]!

 Integration test MR jobs attempt to load htrace jars from the wrong location
 

 Key: HBASE-10830
 URL: https://issues.apache.org/jira/browse/HBASE-10830
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Priority: Minor
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10830.00.patch, HBASE-10830.01.patch


 The MapReduce jobs submitted by IntegrationTestImportTsv want to load the 
 htrace JAR from the local Maven cache but get confused and use a HDFS URI.
 {noformat}
 Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 8.489 sec  
 FAILURE!
 testGenerateAndLoad(org.apache.hadoop.hbase.mapreduce.IntegrationTestImportTsv)
   Time elapsed: 0.488 sec   ERROR!
 java.io.FileNotFoundException: File does not exist: 
 hdfs://localhost:37548/home/apurtell/.m2/repository/org/cloudera/htrace/htrace-core/2.04/htrace-core-2.04.jar
 at 
 org.apache.hadoop.hdfs.DistributedFileSystem$17.doCall(DistributedFileSystem.java:1110)
 at 
 org.apache.hadoop.hdfs.DistributedFileSystem$17.doCall(DistributedFileSystem.java:1102)
 at 
 org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
 at 
 org.apache.hadoop.hdfs.DistributedFileSystem.getFileStatus(DistributedFileSystem.java:1102)
 at 
 org.apache.hadoop.mapreduce.filecache.ClientDistributedCacheManager.getFileStatus(ClientDistributedCacheManager.java:288)
 at 
 org.apache.hadoop.mapreduce.filecache.ClientDistributedCacheManager.getFileStatus(ClientDistributedCacheManager.java:224)
 at 
 org.apache.hadoop.mapreduce.filecache.ClientDistributedCacheManager.determineTimestamps(ClientDistributedCacheManager.java:93)
 at 
 org.apache.hadoop.mapreduce.filecache.ClientDistributedCacheManager.determineTimestampsAndCacheVisibilities(ClientDistributedCacheManager.java:57)
 at 
 org.apache.hadoop.mapreduce.JobSubmitter.copyAndConfigureFiles(JobSubmitter.java:264)
 at 
 org.apache.hadoop.mapreduce.JobSubmitter.copyAndConfigureFiles(JobSubmitter.java:300)
 at 
 org.apache.hadoop.mapreduce.JobSubmitter.submitJobInternal(JobSubmitter.java:387)
 at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1268)
 at org.apache.hadoop.mapreduce.Job$10.run(Job.java:1265)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.Subject.doAs(Subject.java:415)
 at 
 org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1491)
 at org.apache.hadoop.mapreduce.Job.submit(Job.java:1265)
 at org.apache.hadoop.mapreduce.Job.waitForCompletion(Job.java:1286)
 at org.apache.hadoop.hbase.mapreduce.ImportTsv.run(ImportTsv.java:603)
 at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
 at 
 org.apache.hadoop.hbase.mapreduce.TestImportTsv.doMROnTableTest(TestImportTsv.java:270)
 at 
 org.apache.hadoop.hbase.mapreduce.TestImportTsv.doMROnTableTest(TestImportTsv.java:232)
 at 
 org.apache.hadoop.hbase.mapreduce.IntegrationTestImportTsv.testGenerateAndLoad(IntegrationTestImportTsv.java:206)
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10885) Support visibility expressions on Deletes

[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956297#comment-13956297
]

ramkrishna.s.vasudevan commented on HBASE-10885:

Delete.setCellVisibility() should be supported now. And these labels passed
here will be only a list of labels and not visibility expressions like A|B!C?
Which means if an existing put had AB now the delete should pass AB or it
could be A,B like how we pass for Authorization?

Support visibility expressions on Deletes
-

Key: HBASE-10885
URL: https://issues.apache.org/jira/browse/HBASE-10885
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (HBASE-10887) tidy ThriftUtilities format

Liang Xie created HBASE-10887:
-

 Summary: tidy ThriftUtilities format
 Key: HBASE-10887
 URL: https://issues.apache.org/jira/browse/HBASE-10887
 Project: HBase
  Issue Type: Improvement
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liang Xie
Assignee: Liang Xie
Priority: Trivial
 Fix For: 0.99.0
 Attachments: HBASE-10887.txt

Just found the weird code format during reviewing another patch, let's remove 
the unneccessary tab



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10887) tidy ThriftUtilities format


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

Liang Xie updated HBASE-10887:
--

Attachment: HBASE-10887.txt

will commit it shortly, due to just a dummy change

 tidy ThriftUtilities format
 ---

 Key: HBASE-10887
 URL: https://issues.apache.org/jira/browse/HBASE-10887
 Project: HBase
  Issue Type: Improvement
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liang Xie
Assignee: Liang Xie
Priority: Trivial
 Fix For: 0.99.0

 Attachments: HBASE-10887.txt


 Just found the weird code format during reviewing another patch, let's remove 
 the unneccessary tab



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10887) tidy ThriftUtilities format


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

Liang Xie updated HBASE-10887:
--

Fix Version/s: 0.98.1
Affects Version/s: 0.98.1
   Status: Patch Available  (was: Open)

 tidy ThriftUtilities format
 ---

 Key: HBASE-10887
 URL: https://issues.apache.org/jira/browse/HBASE-10887
 Project: HBase
  Issue Type: Improvement
  Components: Thrift
Affects Versions: 0.98.1, 0.99.0
Reporter: Liang Xie
Assignee: Liang Xie
Priority: Trivial
 Fix For: 0.99.0, 0.98.1

 Attachments: HBASE-10887.txt


 Just found the weird code format during reviewing another patch, let's remove 
 the unneccessary tab



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10887) tidy ThriftUtilities format


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

Liang Xie updated HBASE-10887:
--

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

 tidy ThriftUtilities format
 ---

 Key: HBASE-10887
 URL: https://issues.apache.org/jira/browse/HBASE-10887
 Project: HBase
  Issue Type: Improvement
  Components: Thrift
Affects Versions: 0.98.1, 0.99.0
Reporter: Liang Xie
Assignee: Liang Xie
Priority: Trivial
 Fix For: 0.99.0, 0.98.1

 Attachments: HBASE-10887.txt


 Just found the weird code format during reviewing another patch, let's remove 
 the unneccessary tab



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10885) Support visibility expressions on Deletes

[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956348#comment-13956348
]

Andrew Purtell commented on HBASE-10885:

bq. Delete.setCellVisibility() should be supported now.

Yes.

bq. And these labels passed here will be only a list of labels and not
visibility expressions like A|B!C?

No. Deletes should support visibility expressions just like Put, etc. The
supplied visibility expression is then associated with the delete marker(s).

Actually, scratch what I said above in the first comment. I think we can check
that the supplied expression does not exceed the maximal authorization set for
the user submitting the Delete in the preDelete hook and then store the delete
marker as a cell with a visibility expression tag and do the rest of the work
later, by hooking the compaction scanner. The big change then would be checking
for visibility expressions in tags on delete markers at compaction time. If we
find one, then we have to filter only the cells covered by the tombstone that
have a matching expression.

If we are not storing visibility expression terminals (LeafExpressionNodes) in
sorted order by ordinal we probably should consider it. (I don't think we are.)
Because e.g. A|B == B|A. It would be most efficient if we can simply do byte
comparison of serialized visibility expressions.

Support visibility expressions on Deletes
-

Key: HBASE-10885
URL: https://issues.apache.org/jira/browse/HBASE-10885
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10881) Support reverse scan in thrift2

2014-04-01 Thread Liu Shaohui (JIRA)


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

Liu Shaohui updated HBASE-10881:


Attachment: HBASE-10881-trunk-v2.diff

Support reverse scan in thrift(1) too.


 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10881-trunk-v1.diff, HBASE-10881-trunk-v2.diff


 Support reverse scan in thrift2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (HBASE-10885) Support visibility expressions on Deletes

[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956348#comment-13956348
]

Andrew Purtell edited comment on HBASE-10885 at 4/1/14 10:25 AM:
-

bq. Delete.setCellVisibility() should be supported now.

Yes.

bq. And these labels passed here will be only a list of labels and not
visibility expressions like A|B!C?

No. Deletes should support visibility expressions just like Put, etc. The
supplied visibility expression is then associated with the delete marker(s).

If a delete marker has a visibility expression, then we only apply it to cells
with matching visibility expressions. If a cell has no visibility tag then it
does not match. (A|B != nil)

was (Author: apurtell):
bq. Delete.setCellVisibility() should be supported now.

Yes.

bq. And these labels passed here will be only a list of labels and not
visibility expressions like A|B!C?

No. Deletes should support visibility expressions just like Put, etc. The
supplied visibility expression is then associated with the delete marker(s).

Support visibility expressions on Deletes
-

Key: HBASE-10885
URL: https://issues.apache.org/jira/browse/HBASE-10885
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10886) add htrace-zipkin to the runtime dependencies again

[
https://issues.apache.org/jira/browse/HBASE-10886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956352#comment-13956352
]

Hadoop QA commented on HBASE-10886:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12638025/HBASE-10886-0.patch
against trunk revision .
ATTACHMENT ID: 12638025

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:red}-1 tests included{color}. 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:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:green}+1 site{color}. The mvn site goal succeeds with this patch.

{color:red}-1 core tests{color}. The patch failed these unit tests:

org.apache.hadoop.hbase.mapreduce.TestSecureLoadIncrementalHFilesSplitRecovery

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/9154//console

This message is automatically generated.

add htrace-zipkin to the runtime dependencies again
---

Key: HBASE-10886
URL: https://issues.apache.org/jira/browse/HBASE-10886
Project: HBase
Issue Type: Improvement
Reporter: Masatake Iwasaki
Assignee: Masatake Iwasaki
Priority: Minor
Attachments: HBASE-10886-0.patch

Once htrace-zipkin was removed from depencencies in HBASE-9700. Because all
of the depencencies of htrace-zipkin is bundled with HBase now, it is good to
add it for the ease of use.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10885) Support visibility expressions on Deletes

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

Andrew Purtell updated HBASE-10885:
---

Description:
Accumulo can specify visibility expressions for delete markers. During
compaction the cells covered by the tombstone are determined in part by
matching the visibility expression. This is useful for the use case of data set
coalescing, where entries from multiple data sets carrying different labels are
combined into one common large table. Later, a subset of entries can be
conveniently removed using visibility expressions.

Currently doing the same in HBase would only be possible with a custom
coprocessor. Otherwise, a Delete will affect all cells covered by the tombstone
regardless of any visibility expression scoping. This is correct behavior in
that no data spill is possible, but certainly could be surprising, and is only
meant to be transitional. We decided not to support visibility expressions on
Deletes to control the complexity of the initial implementation.

was:
Accumulo can specify visibility expressions for delete markers. During
compaction the cells covered by the tombstone are determined in part by
matching the visibility expression. This is useful for the use case of data set
coalescing, where entries from multiple data sets carrying different labels are
combined into one common large table. Later, a subset of entries can be
conveniently removed using visibility expressions.

Currently doing the same in HBase would only be possible with a custom
coprocessor. Otherwise, a Delete will affect all cells covered by the tombstone
regardless if they are visible to the user issuing the delete or not. This is
correct behavior in that no data spill is possible, but certainly could be
surprising, and is only meant to be transitional. We decided not to support
visibility expressions on Deletes to control the complexity of the initial
implementation.

Support visibility expressions on Deletes
-

Key: HBASE-10885
URL: https://issues.apache.org/jira/browse/HBASE-10885
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

Accumulo can specify visibility expressions for delete markers. During
compaction the cells covered by the tombstone are determined in part by
matching the visibility expression. This is useful for the use case of data
set coalescing, where entries from multiple data sets carrying different
labels are combined into one common large table. Later, a subset of entries
can be conveniently removed using visibility expressions.
Currently doing the same in HBase would only be possible with a custom
coprocessor. Otherwise, a Delete will affect all cells covered by the
tombstone regardless of any visibility expression scoping. This is correct
behavior in that no data spill is possible, but certainly could be
surprising, and is only meant to be transitional. We decided not to support
visibility expressions on Deletes to control the complexity of the initial
implementation.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10883) Restrict the universe of labels and authorizations

2014-04-01 Thread Anoop Sam John (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956365#comment-13956365
 ] 

Anoop Sam John commented on HBASE-10883:


Referring VisibilityLabelsValidator we allow some special characters to be part 
of labels. So this check should contain those also.

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (HBASE-10885) Support visibility expressions on Deletes

[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956348#comment-13956348
]

Andrew Purtell edited comment on HBASE-10885 at 4/1/14 10:40 AM:
-

bq. Delete.setCellVisibility() should be supported now.

Yes.

bq. And these labels passed here will be only a list of labels and not
visibility expressions like A|B!C?

No. Deletes should support visibility expressions just like Put, etc. The
supplied visibility expression is then associated with the delete marker(s).

Actually, scratch what I said above in the first comment. We can store the
delete marker as a cell with a visibility expression tag and do the work later,
by hooking the compaction scanner. We would check for visibility expressions in
tags on delete markers at compaction time. If we find one, then we have to
filter only the cells covered by the tombstone that have a matching expression.

If a delete marker has a visibility expression, then we only apply it to cells
with matching visibility expressions. If a cell has no visibility tag then it
does not match. (A|B != nil)

Should we check that the supplied expression does not exceed the maximal
authorization set for the user submitting the Delete in the preDelete hook? In
other words, should we we allow a user only granted authorization A to submit a
delete with visibility expression A|B? We should not, in my opinion. It is
different for the delete case than others because delete is a destructive
operation. Recommend we answer this question for other op types on another
JIRA, should there be any.

was (Author: apurtell):
bq. Delete.setCellVisibility() should be supported now.

Yes.

bq. And these labels passed here will be only a list of labels and not
visibility expressions like A|B!C?

No. Deletes should support visibility expressions just like Put, etc. The
supplied visibility expression is then associated with the delete marker(s).

If a delete marker has a visibility expression, then we only apply it to cells
with matching visibility expressions. If a cell has no visibility tag then it
does not match. (A|B != nil)

Support visibility expressions on Deletes
-

Key: HBASE-10885
URL: https://issues.apache.org/jira/browse/HBASE-10885
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

Accumulo can specify visibility expressions for delete markers. During
compaction the cells covered by the tombstone are determined in part by
matching the visibility expression. This is useful for the use case of data
set coalescing, where entries from multiple data sets carrying different
labels are combined into one common large table. Later, a subset of entries
can be conveniently removed using visibility expressions.
Currently doing the same in HBase would only be possible with a custom
coprocessor. Otherwise, a Delete will affect all cells covered by the
tombstone regardless of any visibility expression scoping. This is correct
behavior in that no data spill is possible, but certainly could be
surprising, and is only meant to be transitional. We decided not to support
visibility expressions on Deletes to control the complexity of the initial
implementation.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (HBASE-10885) Support visibility expressions on Deletes

[
https://issues.apache.org/jira/browse/HBASE-10885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956348#comment-13956348
]

Andrew Purtell edited comment on HBASE-10885 at 4/1/14 10:42 AM:
-

bq. Delete.setCellVisibility() should be supported now.

Yes.

bq. And these labels passed here will be only a list of labels and not
visibility expressions like A|B!C?

No. Deletes should support visibility expressions just like Put, etc. The
supplied visibility expression is then associated with the delete marker(s).

If a delete marker has a visibility expression, then we only apply it to cells
with matching visibility expressions. If a cell has no visibility tag then it
does not match. (A|B != nil)

Should we check that the supplied expression does not exceed the maximal
authorization set for the user submitting the Delete in the preDelete hook? In
other words, should we we allow a user only granted authorization A to submit a
delete with visibility expression A|B? We should not, in my opinion. Recommend
we answer this question for other op types on another JIRA, should there be any.

was (Author: apurtell):
bq. Delete.setCellVisibility() should be supported now.

Yes.

bq. And these labels passed here will be only a list of labels and not
visibility expressions like A|B!C?

No. Deletes should support visibility expressions just like Put, etc. The
supplied visibility expression is then associated with the delete marker(s).

If a delete marker has a visibility expression, then we only apply it to cells
with matching visibility expressions. If a cell has no visibility tag then it
does not match. (A|B != nil)

Support visibility expressions on Deletes
-

Key: HBASE-10885
URL: https://issues.apache.org/jira/browse/HBASE-10885
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

Accumulo can specify visibility expressions for delete markers. During
compaction the cells covered by the tombstone are determined in part by
matching the visibility expression. This is useful for the use case of data
set coalescing, where entries from multiple data sets carrying different
labels are combined into one common large table. Later, a subset of entries
can be conveniently removed using visibility expressions.
Currently doing the same in HBase would only be possible with a custom
coprocessor. Otherwise, a Delete will affect all cells covered by the
tombstone regardless of any visibility expression scoping. This is correct
behavior in that no data spill is possible, but certainly could be
surprising, and is only meant to be transitional. We decided not to support
visibility expressions on Deletes to control the complexity of the

[jira] [Commented] (HBASE-10883) Restrict the universe of labels and authorizations


[ 
https://issues.apache.org/jira/browse/HBASE-10883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956382#comment-13956382
 ] 

Andrew Purtell commented on HBASE-10883:


{code}
+  private final String regex = [A-Za-z_0-9]*;
{code}

I think this should be

{code}
+  private final String regex = [A-Za-z\\_][A-Za-z0-9\\_\\-]*;
{code}

but this is a minor thing, if you want the other then no problem.

The regex should be precompiled since it may be applied often.

Like Anoop says, we need to validate authorizations and labels the same way now.

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10883) Restrict the universe of labels and authorizations


[ 
https://issues.apache.org/jira/browse/HBASE-10883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956383#comment-13956383
 ] 

Andrew Purtell commented on HBASE-10883:


Well, you do have to change the current regexp somehow because it will match 
the empty string and that's not valid.

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10882) Bulkload process hangs on regions randomly and finally throws RegionTooBusyException

[
https://issues.apache.org/jira/browse/HBASE-10882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956398#comment-13956398
]

Liang Xie commented on HBASE-10882:
---

It would be better to ask at mail list in future:)
Why you have such many table pool instances ?
bq. The most ridiculous thing is NO ONE OWNED THE LOCK! I searched the jstack
output carefully, but cannot find any process who claimed to own the lock.
The thread dump doesn't show the lock holder while using Lock, but you could
see it if using Synchronized.:)

Bulkload process hangs on regions randomly and finally throws
RegionTooBusyException

Key: HBASE-10882
URL: https://issues.apache.org/jira/browse/HBASE-10882
Project: HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.94.10
Environment: rhel 5.6, jdk1.7.0_45, hadoop-2.2.0-cdh5.0.0
Reporter: Victor Xu
Attachments: jstack_5105.log

I came across the problem in the early morning several days ago. It happened
when I used hadoop completebulkload command to bulk load some hdfs files into
hbase table. Several regions hung and after retried three times they all
threw RegionTooBusyExceptions. Fortunately, I caught one of the exceptional
region’s HRegionServer process’s jstack info just in time.
I found that the bulkload process was waiting for a write lock:
at
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
The lock id is 0x0004054ecbf0.
In the meantime, many other Get/Scan operations were also waiting for the
same lock id. And, of course, they were waiting for the read lock:
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.tryLock(ReentrantReadWriteLock.java:873)
The most ridiculous thing is NO ONE OWNED THE LOCK! I searched the jstack
output carefully, but cannot find any process who claimed to own the lock.
When I restart the bulk load process, it failed at different regions but with
the same RegionTooBusyExceptions.
I guess maybe the region was doing some compactions at that time and owned
the lock, but I couldn’t find compaction info in the hbase-logs.
Finally, after several days’ hard work, the only temporary solution to this
problem was found, that is TRIGGERING A MAJOR COMPACTION BEFORE THE BULKLOAD,
So which process owned the lock? Has anyone came across the same problem
before?

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10883) Restrict the universe of labels and authorizations


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

ramkrishna.s.vasudevan updated HBASE-10883:
---

Attachment: HBASE-10883_1.patch

Now validation is sync with VisibilityLabelsValidator.  Also checks for empty 
string or white space String.

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch, HBASE-10883_1.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10883) Restrict the universe of labels and authorizations


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

ramkrishna.s.vasudevan updated HBASE-10883:
---

Status: Patch Available  (was: Open)

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch, HBASE-10883_1.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (HBASE-10883) Restrict the universe of labels and authorizations


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

ramkrishna.s.vasudevan updated HBASE-10883:
---

Status: Open  (was: Patch Available)

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch, HBASE-10883_1.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10883) Restrict the universe of labels and authorizations

2014-04-01 Thread Ashish Singhi (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956436#comment-13956436
 ] 

Ashish Singhi commented on HBASE-10883:
---

Minor nit.
{code}
 } catch (IllegalArgumentException e) {
+  fail(Should have failed for -B);
+}
{code}
Message should be something like should not fail.

 Restrict the universe of labels and authorizations
 --

 Key: HBASE-10883
 URL: https://issues.apache.org/jira/browse/HBASE-10883
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
 Fix For: 0.99.0, 0.98.2

 Attachments: HBASE-10883.patch, HBASE-10883_1.patch


 Currently we allow any string as visibility label or request authorization. 
 However as seen on HBASE-10878, we accept for authorizations strings that 
 would not work if provided as labels in visibility expressions. We should 
 throw an exception at least in cases where someone tries to define or use a 
 label or authorization including visibility expression operators '', '|', 
 '!', '(', ')'.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10883) Restrict the universe of labels and authorizations

[
https://issues.apache.org/jira/browse/HBASE-10883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956450#comment-13956450
]

Hadoop QA commented on HBASE-10883:
---

{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12638028/HBASE-10883.patch
against trunk revision .
ATTACHMENT ID: 12638028

{color:green}+1 @author{color}. The patch does not contain any @author
tags.

{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.

{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.

{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.

{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.

{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100

{color:green}+1 site{color}. The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}. The patch passed unit tests in .

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/9155//console

This message is automatically generated.

Restrict the universe of labels and authorizations
--

Key: HBASE-10883
URL: https://issues.apache.org/jira/browse/HBASE-10883
Project: HBase
Issue Type: Improvement
Affects Versions: 0.98.1
Reporter: Andrew Purtell
Fix For: 0.99.0, 0.98.2

Attachments: HBASE-10883.patch, HBASE-10883_1.patch

Currently we allow any string as visibility label or request authorization.
However as seen on HBASE-10878, we accept for authorizations strings that
would not work if provided as labels in visibility expressions. We should
throw an exception at least in cases where someone tries to define or use a
label or authorization including visibility expression operators '', '|',
'!', '(', ')'.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10881) Support reverse scan in thrift2


[ 
https://issues.apache.org/jira/browse/HBASE-10881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956466#comment-13956466
 ] 

Hadoop QA commented on HBASE-10881:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12638043/HBASE-10881-trunk-v2.diff
  against trunk revision .
  ATTACHMENT ID: 12638043

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 6 new 
or modified tests.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 findbugs{color}.  The patch does not introduce any new 
Findbugs (version 1.3.9) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:red}-1 lineLengths{color}.  The patch introduces the following lines 
longer than 100:
+  private static final org.apache.thrift.protocol.TField 
REVERSED_FIELD_DESC = new org.apache.thrift.protocol.TField(reversed, 
org.apache.thrift.protocol.TType.BOOL, (short)9);
+  private _Fields optionals[] = 
{_Fields.START_ROW,_Fields.STOP_ROW,_Fields.TIMESTAMP,_Fields.COLUMNS,_Fields.CACHING,_Fields.FILTER_STRING,_Fields.BATCH_SIZE,_Fields.SORT_COLUMNS,_Fields.REVERSED};
+tmpMap.put(_Fields.REVERSED, new 
org.apache.thrift.meta_data.FieldMetaData(reversed, 
org.apache.thrift.TFieldRequirementType.OPTIONAL, 
+  private static final org.apache.thrift.protocol.TField REVERSED_FIELD_DESC = 
new org.apache.thrift.protocol.TField(reversed, 
org.apache.thrift.protocol.TType.BOOL, (short)11);
+  private _Fields optionals[] = 
{_Fields.START_ROW,_Fields.STOP_ROW,_Fields.COLUMNS,_Fields.CACHING,_Fields.MAX_VERSIONS,_Fields.TIME_RANGE,_Fields.FILTER_STRING,_Fields.BATCH_SIZE,_Fields.ATTRIBUTES,_Fields.AUTHORIZATIONS,_Fields.REVERSED};
+tmpMap.put(_Fields.REVERSED, new 
org.apache.thrift.meta_data.FieldMetaData(reversed, 
org.apache.thrift.TFieldRequirementType.OPTIONAL, 
+  org.apache.thrift.protocol.TList _list117 = new 
org.apache.thrift.protocol.TList(org.apache.thrift.protocol.TType.STRUCT, 
iprot.readI32());
+  org.apache.thrift.protocol.TMap _map120 = new 
org.apache.thrift.protocol.TMap(org.apache.thrift.protocol.TType.STRING, 
org.apache.thrift.protocol.TType.STRING, iprot.readI32());

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
   org.apache.hadoop.hbase.regionserver.wal.TestLogRolling

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/9156//console

This message is automatically generated.

 Support reverse scan in thrift2
 ---

 Key: HBASE-10881
 URL: https://issues.apache.org/jira/browse/HBASE-10881
 Project: HBase
  Issue Type: New Feature
  Components: Thrift
Affects Versions: 0.99.0
Reporter: Liu Shaohui
Assignee: Liu Shaohui
Priority: Minor
 Fix For: 0.99.0

 Attachments: HBASE-10881-trunk-v1.diff, HBASE-10881-trunk-v2.diff


 Support reverse scan in thrift2.



--
This message was

[jira] [Commented] (HBASE-10887) tidy ThriftUtilities format


[ 
https://issues.apache.org/jira/browse/HBASE-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956477#comment-13956477
 ] 

Hudson commented on HBASE-10887:


SUCCESS: Integrated in HBase-0.98 #259 (See 
[https://builds.apache.org/job/HBase-0.98/259/])
HBASE-10887 tidy ThriftUtilities format (liangxie: rev 1583595)
* 
/hbase/branches/0.98/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftUtilities.java


 tidy ThriftUtilities format
 ---

 Key: HBASE-10887
 URL: https://issues.apache.org/jira/browse/HBASE-10887
 Project: HBase
  Issue Type: Improvement
  Components: Thrift
Affects Versions: 0.98.1, 0.99.0
Reporter: Liang Xie
Assignee: Liang Xie
Priority: Trivial
 Fix For: 0.98.1, 0.99.0

 Attachments: HBASE-10887.txt


 Just found the weird code format during reviewing another patch, let's remove 
 the unneccessary tab



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10887) tidy ThriftUtilities format


[ 
https://issues.apache.org/jira/browse/HBASE-10887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13956509#comment-13956509
 ] 

Hudson commented on HBASE-10887:


FAILURE: Integrated in HBase-0.98-on-Hadoop-1.1 #243 (See 
[https://builds.apache.org/job/HBase-0.98-on-Hadoop-1.1/243/])
HBASE-10887 tidy ThriftUtilities format (liangxie: rev 1583595)
* 
/hbase/branches/0.98/hbase-thrift/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftUtilities.java


 tidy ThriftUtilities format
 ---

 Key: HBASE-10887
 URL: https://issues.apache.org/jira/browse/HBASE-10887
 Project: HBase
  Issue Type: Improvement
  Components: Thrift
Affects Versions: 0.98.1, 0.99.0
Reporter: Liang Xie
Assignee: Liang Xie
Priority: Trivial
 Fix For: 0.98.1, 0.99.0

 Attachments: HBASE-10887.txt


 Just found the weird code format during reviewing another patch, let's remove 
 the unneccessary tab



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (HBASE-10883) Restrict the universe of labels and authorizations