[jira] [Updated] (HBASE-9306) [0.92] TestAdmin.testCreateBadTables fails occasionally

2013-08-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-9306:
--

Attachment: 9306.patch

Triage the concurrent part of TestAdmin.testCreateBadTables by commenting it 
out.

 [0.92] TestAdmin.testCreateBadTables fails occasionally
 ---

 Key: HBASE-9306
 URL: https://issues.apache.org/jira/browse/HBASE-9306
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: 9306.patch


 A typical failure:
 {noformat}
 java.lang.AssertionError: expected:9 but was:8
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at org.junit.Assert.assertEquals(Assert.java:456)
   at 
 org.apache.hadoop.hbase.client.TestAdmin.testCreateBadTables(TestAdmin.java:996)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (HBASE-9306) [0.92] TestAdmin.testCreateBadTables fails occasionally

2013-08-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell resolved HBASE-9306.
---

   Resolution: Fixed
Fix Version/s: 0.92.3

 [0.92] TestAdmin.testCreateBadTables fails occasionally
 ---

 Key: HBASE-9306
 URL: https://issues.apache.org/jira/browse/HBASE-9306
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.92.3

 Attachments: 9306.patch


 A typical failure:
 {noformat}
 java.lang.AssertionError: expected:9 but was:8
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at org.junit.Assert.assertEquals(Assert.java:456)
   at 
 org.apache.hadoop.hbase.client.TestAdmin.testCreateBadTables(TestAdmin.java:996)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9304) [0.92] TestDrainingServer fails occasionally

2013-08-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-9304:
--

Attachment: 9304.patch

Block until no regions in transition and invoke the balancer like we do in the 
0.94 version of this test.

 [0.92] TestDrainingServer fails occasionally
 

 Key: HBASE-9304
 URL: https://issues.apache.org/jira/browse/HBASE-9304
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: 9304.patch


 The error is the same in every case:
 {noformat}
 junit.framework.AssertionFailedError
   at junit.framework.Assert.fail(Assert.java:48)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at junit.framework.Assert.assertFalse(Assert.java:34)
   at junit.framework.Assert.assertFalse(Assert.java:41)
   at 
 org.apache.hadoop.hbase.TestDrainingServer.setUpBeforeClass(TestDrainingServer.java:78)
 {noformat}
 This is a check at test startup that every regionserver has an assignment. 
 Looks like sometimes it takes a long time for the cluster to come up - there 
 are 5 RSes started - and not all get region assignments. Probably a test only 
 fix here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (HBASE-9304) [0.92] TestDrainingServer fails occasionally

2013-08-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell resolved HBASE-9304.
---

   Resolution: Fixed
Fix Version/s: 0.92.3

 [0.92] TestDrainingServer fails occasionally
 

 Key: HBASE-9304
 URL: https://issues.apache.org/jira/browse/HBASE-9304
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.92.3

 Attachments: 9304.patch


 The error is the same in every case:
 {noformat}
 junit.framework.AssertionFailedError
   at junit.framework.Assert.fail(Assert.java:48)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at junit.framework.Assert.assertFalse(Assert.java:34)
   at junit.framework.Assert.assertFalse(Assert.java:41)
   at 
 org.apache.hadoop.hbase.TestDrainingServer.setUpBeforeClass(TestDrainingServer.java:78)
 {noformat}
 This is a check at test startup that every regionserver has an assignment. 
 Looks like sometimes it takes a long time for the cluster to come up - there 
 are 5 RSes started - and not all get region assignments. Probably a test only 
 fix here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9305) [0.92] TestFromClientSide.testCacheOnWriteEvictOnClose fails occasionally

2013-08-26 Thread Andrew Purtell (JIRA)

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

Andrew Purtell updated HBASE-9305:
--

Attachment: 9305.patch

Triage by not checking hit counts at the problematic point in the test. May 
just move the problem. Testing.

 [0.92] TestFromClientSide.testCacheOnWriteEvictOnClose fails occasionally
 -

 Key: HBASE-9305
 URL: https://issues.apache.org/jira/browse/HBASE-9305
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Attachments: 9305.patch


 The assertion failures are like this:
 {noformat}
 java.lang.AssertionError: expected:2089 but was:2109
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at org.junit.Assert.assertEquals(Assert.java:456)
   at 
 org.apache.hadoop.hbase.client.TestFromClientSide.testCacheOnWriteEvictOnClose(TestFromClientSide.java:4248)
 {noformat}
 Also:
 {noformat}
 expected:2067 but was:2087
 {noformat}
 {noformat}
 expected:2070 but was:2090
 {noformat}
 The test saves off the current block cache stats - block count and hits and 
 misses - then puts a value and gets it back:
 {code}
 4242: Put put = new Put(ROW);
 4243: put.add(FAMILY, QUALIFIER, data);
 4244: table.put(put);
 4245: assertTrue(Bytes.equals(table.get(new Get(ROW)).value(), data));
 {code}
 then we have these asserts:
 {code}
 4246: //data was in memstore so don't expect any changes
 4247: assertEquals(startBlockCount, cache.getBlockCount());
 4248: assertEquals(startBlockHits, cache.getStats().getHitCount());
 4249: assertEquals(startBlockMiss, cache.getStats().getMissCount());
 {code}
 There are exactly 20 more hits than expected every time. In the log looks 
 like there's a meta scan happening around the same time. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9116) Add a view/edit tool for favored node mappings for regions

2013-08-26 Thread Devaraj Das (JIRA)

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

Devaraj Das updated HBASE-9116:
---

Attachment: 9116-4.txt

Added tests for verifying assignment when RSs are lost (regions for which this 
RS was primary should move to the secondaries).

 Add a view/edit tool for favored node mappings for regions
 --

 Key: HBASE-9116
 URL: https://issues.apache.org/jira/browse/HBASE-9116
 Project: HBase
  Issue Type: Improvement
  Components: Region Assignment
Affects Versions: 0.95.0
Reporter: Devaraj Das
Assignee: Devaraj Das
 Fix For: 0.96.0

 Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, 
 9116-3.txt, 9116-4.txt


 Add a tool that one can run offline to view the favored node mappings for 
 regions, and also fix the mappings if needed. Such a tool exists in the 
 0.89-fb branch. Will port it over to trunk/0.95.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9283) Struct and StructIterator should properly handle trailing nulls

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk updated HBASE-9283:


Attachment: 0001-HBASE-9283-Struct-trailing-null-handling.patch

I realized I don't need to push this position checking down into the DataType 
implementations. This patch keeps the null extension logic localized to Struct 
and StructIterator. I'll post one more version tomorrow which updates the docs.

 Struct and StructIterator should properly handle trailing nulls
 ---

 Key: HBASE-9283
 URL: https://issues.apache.org/jira/browse/HBASE-9283
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 0001-HBASE-9283-Struct-trailing-null-handling.patch, 
 0001-HBASE-9283-Struct-trailing-null-handling.patch


 For a composite row key, Phoenix strips off trailing null columns values in 
 the row key. The reason this is important is that then new nullable row key 
 columns can be added to a schema without requiring any data upgrade to 
 existing rows. Otherwise, adding new row key columns to the end of a schema 
 becomes extremely cumbersome, as you'd need to delete all existing rows and 
 add them back with a row key that includes a null value.
 Rather than Phoenix needing to modify the iteration code everywhere (as 
 [~ndimiduk] outlined here: 
 https://issues.apache.org/jira/browse/HBASE-8693?focusedCommentId=13744499page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13744499),
  it'd be better if StructIterator handled this out-of-the-box. Otherwise, if 
 Phoenix has to specialize this, we'd lose the interop piece which is the 
 justification for switching our type system to this new one in the first 
 place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9306) [0.92] TestAdmin.testCreateBadTables fails occasionally

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9306:
---

SUCCESS: Integrated in HBase-0.92 #620 (See 
[https://builds.apache.org/job/HBase-0.92/620/])
HBASE-9306. [0.92] TestAdmin.testCreateBadTables fails occasionally (apurtell: 
rev 1517429)
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/client/TestAdmin.java


 [0.92] TestAdmin.testCreateBadTables fails occasionally
 ---

 Key: HBASE-9306
 URL: https://issues.apache.org/jira/browse/HBASE-9306
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.92.3

 Attachments: 9306.patch


 A typical failure:
 {noformat}
 java.lang.AssertionError: expected:9 but was:8
   at org.junit.Assert.fail(Assert.java:93)
   at org.junit.Assert.failNotEquals(Assert.java:647)
   at org.junit.Assert.assertEquals(Assert.java:128)
   at org.junit.Assert.assertEquals(Assert.java:472)
   at org.junit.Assert.assertEquals(Assert.java:456)
   at 
 org.apache.hadoop.hbase.client.TestAdmin.testCreateBadTables(TestAdmin.java:996)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9304) [0.92] TestDrainingServer fails occasionally

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9304:
---

SUCCESS: Integrated in HBase-0.92 #620 (See 
[https://builds.apache.org/job/HBase-0.92/620/])
HBASE-9304. [0.92] TestDrainingServer fails occasionally (apurtell: rev 1517431)
* 
/hbase/branches/0.92/src/test/java/org/apache/hadoop/hbase/TestDrainingServer.java


 [0.92] TestDrainingServer fails occasionally
 

 Key: HBASE-9304
 URL: https://issues.apache.org/jira/browse/HBASE-9304
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.92.3
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.92.3

 Attachments: 9304.patch


 The error is the same in every case:
 {noformat}
 junit.framework.AssertionFailedError
   at junit.framework.Assert.fail(Assert.java:48)
   at junit.framework.Assert.assertTrue(Assert.java:20)
   at junit.framework.Assert.assertFalse(Assert.java:34)
   at junit.framework.Assert.assertFalse(Assert.java:41)
   at 
 org.apache.hadoop.hbase.TestDrainingServer.setUpBeforeClass(TestDrainingServer.java:78)
 {noformat}
 This is a check at test startup that every regionserver has an assignment. 
 Looks like sometimes it takes a long time for the cluster to come up - there 
 are 5 RSes started - and not all get region assignments. Probably a test only 
 fix here.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-8201) OrderedBytes: an ordered encoding strategy

2013-08-26 Thread He Liangliang (JIRA)

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

He Liangliang commented on HBASE-8201:
--

Hi Nick,
Will fixed int8/byte and fixed int16/short be supported?

 OrderedBytes: an ordered encoding strategy
 --

 Key: HBASE-8201
 URL: https://issues.apache.org/jira/browse/HBASE-8201
 Project: HBase
  Issue Type: Sub-task
  Components: Client
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.95.2

 Attachments: 
 0001-HBASE-8201-OrderedBytes-order-preserving-encoding.patch, 
 0001-HBASE-8201-OrderedBytes-order-preserving-encoding.patch, 
 0001-HBASE-8201-OrderedBytes-order-preserving-encoding.patch, 
 0001-HBASE-8201-OrderedBytes-order-preserving-encoding.patch, 
 0001-HBASE-8201-OrderedBytes-order-preserving-encoding.patch, 
 0001-HBASE-8201-OrderedBytes-order-preserving-encoding.patch, 
 0001-HBASE-8201-OrderedBytes-order-preserving-encoding.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch, 
 0001-HBASE-8201-OrderedBytes-provides-order-preserving-se.patch


 Once the spec is agreed upon, it must be implemented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-7709) Infinite loop possible in Master/Master replication

2013-08-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-7709:
--

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

{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:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6896//console

This message is automatically generated.

 Infinite loop possible in Master/Master replication
 ---

 Key: HBASE-7709
 URL: https://issues.apache.org/jira/browse/HBASE-7709
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.94.6, 0.95.1
Reporter: Lars Hofhansl
Assignee: Vasu Mariyala
 Fix For: 0.98.0, 0.94.12, 0.96.0

 Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, 
 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, 
 HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, 
 HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch


  We just discovered the following scenario:
 # Cluster A and B are setup in master/master replication
 # By accident we had Cluster C replicate to Cluster A.
 Now all edit originating from C will be bouncing between A and B. Forever!
 The reason is that when the edit come in from C the cluster ID is already set 
 and won't be reset.
 We have a couple of options here:
 # Optionally only support master/master (not cycles of more than two 
 clusters). In that case we can always reset the cluster ID in the 
 ReplicationSource. That means that now cycles  2 will have the data cycle 
 forever. This is the only option that requires no changes in the HLog format.
 # Instead of a single cluster id per edit maintain a (unordered) set of 
 cluster id that have seen this edit. Then in ReplicationSource we drop any 
 edit that the sink has seen already. The is the cleanest approach, but it 
 might need a lot of data stored per edit if there are many clusters involved.
 # Maintain a configurable counter of the maximum cycle side we want to 
 support. Could default to 10 (even maybe even just). Store a hop-count in the 
 WAL and the ReplicationSource increases that hop-count on each hop. If we're 
 over the max, just drop the edit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk updated HBASE-9332:


Attachment: 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch

re-attaching patch for build bot.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9329) SnapshotManager should check for directory existance before throwing a warning.

2013-08-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-9329:
---

   Resolution: Fixed
Fix Version/s: 0.95.2
   0.94.12
   0.98.0
   Status: Resolved  (was: Patch Available)

committed to 0.94, 0.95 and trunk, thanks for the patch

 SnapshotManager should check for directory existance before throwing a 
 warning.
 ---

 Key: HBASE-9329
 URL: https://issues.apache.org/jira/browse/HBASE-9329
 Project: HBase
  Issue Type: Bug
  Components: snapshots
Affects Versions: 0.98.0, 0.95.2, 0.94.11
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Trivial
 Fix For: 0.98.0, 0.94.12, 0.95.2

 Attachments: HBASE-9329-v0-trunk.patch


 {quote}
 2013-08-23 17:57:24,277 WARN 
 org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete 
 working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
 {quote}
 I don't have any .hbase-snapshot directory, so there is no need to try to 
 delete the .tmp directory into it. Might first need to check if this 
 directory exist.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9321) Contention getting the current user in RpcClient$Connection.writeRequest

2013-08-26 Thread Jimmy Xiang (JIRA)

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

Jimmy Xiang commented on HBASE-9321:


For this issue, how should be move ahead? To support impersonation, we can 
either create a new connection/hconnection per user, or reuse the connection 
among users if proxy user is supported.  If one connection per user, we may 
have many connections if there are many users.  To reuse the connection, we can 
either check the current user so that clients can use doAs, or we can use some 
client RPC context to pass the user info down with threadlocal variables.

 Contention getting the current user in RpcClient$Connection.writeRequest
 

 Key: HBASE-9321
 URL: https://issues.apache.org/jira/browse/HBASE-9321
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Jean-Daniel Cryans
 Fix For: 0.98.0, 0.96.0

 Attachments: trunk-9321.patch


 I've been running tests on clusters with lots of regions, about 400, and 
 I'm seeing weird contention in the client.
 This one I see a lot, hundreds and sometimes thousands of threads are blocked 
 like this:
 {noformat}
 htable-pool4-t74 daemon prio=10 tid=0x7f2254114000 nid=0x2a99 waiting 
 for monitor entry [0x7f21f9e94000]
java.lang.Thread.State: BLOCKED (on object monitor)
   at 
 org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:466)
   - waiting to lock 0xfb5ad000 (a java.lang.Class for 
 org.apache.hadoop.security.UserGroupInformation)
   at 
 org.apache.hadoop.hbase.ipc.RpcClient$Connection.writeRequest(RpcClient.java:1013)
   at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1407)
   at 
 org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1634)
   at 
 org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1691)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.multi(ClientProtos.java:27339)
   at 
 org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:105)
   at 
 org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:43)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:183)
 {noformat}
 While the holder is doing this:
 {noformat}
 htable-pool17-t55 daemon prio=10 tid=0x7f2244408000 nid=0x2a98 runnable 
 [0x7f21f9f95000]
java.lang.Thread.State: RUNNABLE
   at java.security.AccessController.getStackAccessControlContext(Native 
 Method)
   at java.security.AccessController.getContext(AccessController.java:487)
   at 
 org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:466)
   - locked 0xfb5ad000 (a java.lang.Class for 
 org.apache.hadoop.security.UserGroupInformation)
   at 
 org.apache.hadoop.hbase.ipc.RpcClient$Connection.writeRequest(RpcClient.java:1013)
   at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1407)
   at 
 org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1634)
   at 
 org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1691)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.multi(ClientProtos.java:27339)
   at 
 org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:105)
   at 
 org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:43)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:183)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk updated HBASE-9332:


Attachment: 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch

Update patch to clean findbugs warning.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9281) user_permission command encounters NullPointerException

2013-08-26 Thread Ted Yu (JIRA)

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

Ted Yu updated HBASE-9281:
--

Attachment: 9281.addendum

'user_permission' command encounters the following error:
{code}
ERROR: no method 'toStringBinary' for arguments 
(org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
  available overloads:
(java.nio.ByteBuffer)
(byte[])
Backtrace: /usr/lib/hbase/bin/../lib/ruby/hbase/security.rb:190:in 
`user_permission'
   
file:/usr/lib/hbase/lib/jruby-complete-1.6.8.jar!/builtin/java/java.util.rb:7:in
 `each'
   /usr/lib/hbase/bin/../lib/ruby/hbase/security.rb:188:in 
`user_permission'
   
/usr/lib/hbase/bin/../lib/ruby/shell/commands/user_permission.rb:39:in `command'
   org/jruby/RubyKernel.java:2105:in `send'
   /usr/lib/hbase/bin/../lib/ruby/shell/commands.rb:34:in `command_safe'
   /usr/lib/hbase/bin/../lib/ruby/shell/commands.rb:87:in 
`translate_hbase_exceptions'
   /usr/lib/hbase/bin/../lib/ruby/shell/commands.rb:34:in `command_safe'
   /usr/lib/hbase/bin/../lib/ruby/shell.rb:123:in `internal_command'
   /usr/lib/hbase/bin/../lib/ruby/shell.rb:115:in `command'
   (eval):2:in `user_permission'
{code}
Addendum makes 'user_permission' command work.
{code}
hbase(main):002:0 user_permission
User Table,Family,Qualifier:Permission
 hrt_qa  hbase:acl,,: [Permission: 
actions=CREATE]
1 row(s) in 1.7770 seconds
{code}

 user_permission command encounters NullPointerException
 ---

 Key: HBASE-9281
 URL: https://issues.apache.org/jira/browse/HBASE-9281
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Ted Yu
Assignee: Ted Yu
 Attachments: 9281.addendum, 9281-v1.txt


 As user hbase, user_permission command gave:
 {code}
 java.io.IOException: java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2147)
   ... 1 more
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at 
 org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
   at 
 org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:235)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.execService(ProtobufUtil.java:1304)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:87)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:84)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:120)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:98)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel.callExecService(RegionCoprocessorRpcChannel.java:90)
   at 
 org.apache.hadoop.hbase.ipc.CoprocessorRpcChannel.callBlockingMethod(CoprocessorRpcChannel.java:67)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$BlockingStub.getUserPermissions(AccessControlProtos.java:10304)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getUserPermissions(ProtobufUtil.java:1974)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 

[jira] [Commented] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-9332:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12599967/0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch
  against trunk revision .

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

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

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

{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:red}-1 release audit{color}.  The applied patch generated 2 release 
audit warnings (more than the trunk's current 0 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/6897//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6897//console

This message is automatically generated.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9336) Two css files raise release audit warning

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk updated HBASE-9336:


Attachment: 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch

Fix audit warnings. I just duplicated the license header from bootstrap.css. 
[~eclark] let me know if you want to see something different.

 Two css files raise release audit warning
 -

 Key: HBASE-9336
 URL: https://issues.apache.org/jira/browse/HBASE-9336
 Project: HBase
  Issue Type: Task
Reporter: Ted Yu
 Attachments: 
 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch


 From 
 https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
  :
 {code}
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
 Lines that start with ? in the release audit report indicate files that 
 do not have an Apache license header.
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-7709) Infinite loop possible in Master/Master replication

2013-08-26 Thread Vasu Mariyala (JIRA)

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

Vasu Mariyala commented on HBASE-7709:
--

The patch HBASE-7709-rev5.patch is on the top of 0.94 and hence the hadoop qa 
would always fail while applying this patch on trunk. Can any one please run 
the hadoop qa build for the patch 0.95-trunk-rev4.patch (which is the trunk 
and 0.95 patch)?

 Infinite loop possible in Master/Master replication
 ---

 Key: HBASE-7709
 URL: https://issues.apache.org/jira/browse/HBASE-7709
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.94.6, 0.95.1
Reporter: Lars Hofhansl
Assignee: Vasu Mariyala
 Fix For: 0.98.0, 0.94.12, 0.96.0

 Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, 
 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, 
 HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, 
 HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch


  We just discovered the following scenario:
 # Cluster A and B are setup in master/master replication
 # By accident we had Cluster C replicate to Cluster A.
 Now all edit originating from C will be bouncing between A and B. Forever!
 The reason is that when the edit come in from C the cluster ID is already set 
 and won't be reset.
 We have a couple of options here:
 # Optionally only support master/master (not cycles of more than two 
 clusters). In that case we can always reset the cluster ID in the 
 ReplicationSource. That means that now cycles  2 will have the data cycle 
 forever. This is the only option that requires no changes in the HLog format.
 # Instead of a single cluster id per edit maintain a (unordered) set of 
 cluster id that have seen this edit. Then in ReplicationSource we drop any 
 edit that the sink has seen already. The is the cleanest approach, but it 
 might need a lot of data stored per edit if there are many clusters involved.
 # Maintain a configurable counter of the maximum cycle side we want to 
 support. Could default to 10 (even maybe even just). Store a hop-count in the 
 WAL and the ReplicationSource increases that hop-count on each hop. If we're 
 over the max, just drop the edit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9336) Two css files raise release audit warning

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk updated HBASE-9336:


Status: Patch Available  (was: Open)

 Two css files raise release audit warning
 -

 Key: HBASE-9336
 URL: https://issues.apache.org/jira/browse/HBASE-9336
 Project: HBase
  Issue Type: Task
Reporter: Ted Yu
 Attachments: 
 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch


 From 
 https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
  :
 {code}
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
 Lines that start with ? in the release audit report indicate files that 
 do not have an Apache license header.
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (HBASE-9336) Two css files raise release audit warning

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk reassigned HBASE-9336:
---

Assignee: Nick Dimiduk

 Two css files raise release audit warning
 -

 Key: HBASE-9336
 URL: https://issues.apache.org/jira/browse/HBASE-9336
 Project: HBase
  Issue Type: Task
Reporter: Ted Yu
Assignee: Nick Dimiduk
 Attachments: 
 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch


 From 
 https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
  :
 {code}
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
 Lines that start with ? in the release audit report indicate files that 
 do not have an Apache license header.
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-7709) Infinite loop possible in Master/Master replication

2013-08-26 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-7709:
---

Please attach 0.95-trunk-rev4.patch one more time - Hadoop QA picks up the 
latest attachment

 Infinite loop possible in Master/Master replication
 ---

 Key: HBASE-7709
 URL: https://issues.apache.org/jira/browse/HBASE-7709
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.94.6, 0.95.1
Reporter: Lars Hofhansl
Assignee: Vasu Mariyala
 Fix For: 0.98.0, 0.94.12, 0.96.0

 Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, 
 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, 
 HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, 
 HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch


  We just discovered the following scenario:
 # Cluster A and B are setup in master/master replication
 # By accident we had Cluster C replicate to Cluster A.
 Now all edit originating from C will be bouncing between A and B. Forever!
 The reason is that when the edit come in from C the cluster ID is already set 
 and won't be reset.
 We have a couple of options here:
 # Optionally only support master/master (not cycles of more than two 
 clusters). In that case we can always reset the cluster ID in the 
 ReplicationSource. That means that now cycles  2 will have the data cycle 
 forever. This is the only option that requires no changes in the HLog format.
 # Instead of a single cluster id per edit maintain a (unordered) set of 
 cluster id that have seen this edit. Then in ReplicationSource we drop any 
 edit that the sink has seen already. The is the cleanest approach, but it 
 might need a lot of data stored per edit if there are many clusters involved.
 # Maintain a configurable counter of the maximum cycle side we want to 
 support. Could default to 10 (even maybe even just). Store a hop-count in the 
 WAL and the ReplicationSource increases that hop-count on each hop. If we're 
 over the max, just drop the edit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk commented on HBASE-9332:
-

Release audit issues are fixed by HBASE-9336.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9336) Two css files raise release audit warning

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9336:
--

[~ndimiduk] Does the patch fix the audit warnings?

 Two css files raise release audit warning
 -

 Key: HBASE-9336
 URL: https://issues.apache.org/jira/browse/HBASE-9336
 Project: HBase
  Issue Type: Task
Reporter: Ted Yu
Assignee: Nick Dimiduk
 Attachments: 
 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch


 From 
 https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
  :
 {code}
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
 Lines that start with ? in the release audit report indicate files that 
 do not have an Apache license header.
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread Matteo Bertozzi (JIRA)
Matteo Bertozzi created HBASE-9337:
--

 Summary: shell 'user_permission' throws no method 'toStringBinary' 
for (o.a.h.h.TableName) 
 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0


the user_permission shell code is trying to convert a TableName object to a 
string, and it throws
{code}
hbase(main):010:0 user_permission 
UserTable,Family,Qualifier:Permission   



ERROR: no method 'toStringBinary' for arguments 
(org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
  available overloads:
(java.nio.ByteBuffer)
(byte[])
{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-9337:
---

Status: Patch Available  (was: Open)

 shell 'user_permission' throws no method 'toStringBinary' for 
 (o.a.h.h.TableName) 
 --

 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9337-v0.patch


 the user_permission shell code is trying to convert a TableName object to a 
 string, and it throws
 {code}
 hbase(main):010:0 user_permission 
 UserTable,Family,Qualifier:Permission 
   
 
 ERROR: no method 'toStringBinary' for arguments 
 (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
   available overloads:
 (java.nio.ByteBuffer)
 (byte[])
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-9337:
---

Attachment: HBASE-9337-v0.patch

 shell 'user_permission' throws no method 'toStringBinary' for 
 (o.a.h.h.TableName) 
 --

 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9337-v0.patch


 the user_permission shell code is trying to convert a TableName object to a 
 string, and it throws
 {code}
 hbase(main):010:0 user_permission 
 UserTable,Family,Qualifier:Permission 
   
 
 ERROR: no method 'toStringBinary' for arguments 
 (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
   available overloads:
 (java.nio.ByteBuffer)
 (byte[])
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9336) Two css files raise release audit warning

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk commented on HBASE-9336:
-

Works for me locally.

 Two css files raise release audit warning
 -

 Key: HBASE-9336
 URL: https://issues.apache.org/jira/browse/HBASE-9336
 Project: HBase
  Issue Type: Task
Reporter: Ted Yu
Assignee: Nick Dimiduk
 Attachments: 
 0001-HBASE-9336-Add-missing-license-headers-to-css-files.patch


 From 
 https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
  :
 {code}
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
  !? 
 /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
 Lines that start with ? in the release audit report indicate files that 
 do not have an Apache license header.
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread Nicolas Liochon (JIRA)

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

Nicolas Liochon commented on HBASE-9332:


I'm +1, if there is no objection I will commit soon (within 1 hour) to get it 
into the next 0.95 release.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9337:
--

+1 (Thanks for looking at security code path)

 shell 'user_permission' throws no method 'toStringBinary' for 
 (o.a.h.h.TableName) 
 --

 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9337-v0.patch


 the user_permission shell code is trying to convert a TableName object to a 
 string, and it throws
 {code}
 hbase(main):010:0 user_permission 
 UserTable,Family,Qualifier:Permission 
   
 
 ERROR: no method 'toStringBinary' for arguments 
 (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
   available overloads:
 (java.nio.ByteBuffer)
 (byte[])
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9337:
--

+1 for trunk and 0.95

 shell 'user_permission' throws no method 'toStringBinary' for 
 (o.a.h.h.TableName) 
 --

 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9337-v0.patch


 the user_permission shell code is trying to convert a TableName object to a 
 string, and it throws
 {code}
 hbase(main):010:0 user_permission 
 UserTable,Family,Qualifier:Permission 
   
 
 ERROR: no method 'toStringBinary' for arguments 
 (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
   available overloads:
 (java.nio.ByteBuffer)
 (byte[])
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-7709) Infinite loop possible in Master/Master replication

2013-08-26 Thread Vasu Mariyala (JIRA)

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

Vasu Mariyala updated HBASE-7709:
-

Attachment: (was: 0.95-trunk-rev4.patch)

 Infinite loop possible in Master/Master replication
 ---

 Key: HBASE-7709
 URL: https://issues.apache.org/jira/browse/HBASE-7709
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.94.6, 0.95.1
Reporter: Lars Hofhansl
Assignee: Vasu Mariyala
 Fix For: 0.98.0, 0.94.12, 0.96.0

 Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, 
 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, HBASE-7709.patch, 
 HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, HBASE-7709-rev3.patch, 
 HBASE-7709-rev4.patch, HBASE-7709-rev5.patch


  We just discovered the following scenario:
 # Cluster A and B are setup in master/master replication
 # By accident we had Cluster C replicate to Cluster A.
 Now all edit originating from C will be bouncing between A and B. Forever!
 The reason is that when the edit come in from C the cluster ID is already set 
 and won't be reset.
 We have a couple of options here:
 # Optionally only support master/master (not cycles of more than two 
 clusters). In that case we can always reset the cluster ID in the 
 ReplicationSource. That means that now cycles  2 will have the data cycle 
 forever. This is the only option that requires no changes in the HLog format.
 # Instead of a single cluster id per edit maintain a (unordered) set of 
 cluster id that have seen this edit. Then in ReplicationSource we drop any 
 edit that the sink has seen already. The is the cleanest approach, but it 
 might need a lot of data stored per edit if there are many clusters involved.
 # Maintain a configurable counter of the maximum cycle side we want to 
 support. Could default to 10 (even maybe even just). Store a hop-count in the 
 WAL and the ReplicationSource increases that hop-count on each hop. If we're 
 over the max, just drop the edit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9332:
--

+1  Skimmed.  Looks fine.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-7709) Infinite loop possible in Master/Master replication

2013-08-26 Thread Vasu Mariyala (JIRA)

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

Vasu Mariyala updated HBASE-7709:
-

Attachment: 0.95-trunk-rev4.patch

Attaching the patch again

 Infinite loop possible in Master/Master replication
 ---

 Key: HBASE-7709
 URL: https://issues.apache.org/jira/browse/HBASE-7709
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.94.6, 0.95.1
Reporter: Lars Hofhansl
Assignee: Vasu Mariyala
 Fix For: 0.98.0, 0.94.12, 0.96.0

 Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, 
 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, 
 HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, 
 HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch


  We just discovered the following scenario:
 # Cluster A and B are setup in master/master replication
 # By accident we had Cluster C replicate to Cluster A.
 Now all edit originating from C will be bouncing between A and B. Forever!
 The reason is that when the edit come in from C the cluster ID is already set 
 and won't be reset.
 We have a couple of options here:
 # Optionally only support master/master (not cycles of more than two 
 clusters). In that case we can always reset the cluster ID in the 
 ReplicationSource. That means that now cycles  2 will have the data cycle 
 forever. This is the only option that requires no changes in the HLog format.
 # Instead of a single cluster id per edit maintain a (unordered) set of 
 cluster id that have seen this edit. Then in ReplicationSource we drop any 
 edit that the sink has seen already. The is the cleanest approach, but it 
 might need a lot of data stored per edit if there are many clusters involved.
 # Maintain a configurable counter of the maximum cycle side we want to 
 support. Could default to 10 (even maybe even just). Store a hop-count in the 
 WAL and the ReplicationSource increases that hop-count on each hop. If we're 
 over the max, just drop the edit.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9116) Add a view/edit tool for favored node mappings for regions

2013-08-26 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-9116:
---

lgtm

 Add a view/edit tool for favored node mappings for regions
 --

 Key: HBASE-9116
 URL: https://issues.apache.org/jira/browse/HBASE-9116
 Project: HBase
  Issue Type: Improvement
  Components: Region Assignment
Affects Versions: 0.95.0
Reporter: Devaraj Das
Assignee: Devaraj Das
 Fix For: 0.96.0

 Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, 
 9116-3.txt, 9116-4.txt


 Add a tool that one can run offline to view the favored node mappings for 
 regions, and also fix the mappings if needed. Such a tool exists in the 
 0.89-fb branch. Will port it over to trunk/0.95.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9281) user_permission command encounters NullPointerException

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk commented on HBASE-9281:
-

{noformat}
-table = (value.getTable != nil) ? 
org.apache.hadoop.hbase.util.Bytes::toStringBinary(value.getTable) : ''
+table = (value.getTable != nil) ? value.getTable.toString : ''
{noformat}

This should use {{value.getTable.getNameAsString}} instead of {{toString}} -- 
just in case someone wants to make a more expressive toString later on.

Unrelated to your patch, all these {{!= nil}} checks should use the provided 
{{hasXXX}} interfaces instead.

 user_permission command encounters NullPointerException
 ---

 Key: HBASE-9281
 URL: https://issues.apache.org/jira/browse/HBASE-9281
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Ted Yu
Assignee: Ted Yu
 Attachments: 9281.addendum, 9281-v1.txt


 As user hbase, user_permission command gave:
 {code}
 java.io.IOException: java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2147)
   ... 1 more
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at 
 org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
   at 
 org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:235)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.execService(ProtobufUtil.java:1304)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:87)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:84)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:120)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:98)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel.callExecService(RegionCoprocessorRpcChannel.java:90)
   at 
 org.apache.hadoop.hbase.ipc.CoprocessorRpcChannel.callBlockingMethod(CoprocessorRpcChannel.java:67)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$BlockingStub.getUserPermissions(AccessControlProtos.java:10304)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getUserPermissions(ProtobufUtil.java:1974)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
 ...
 Caused by: 
 org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException): 
 java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 

[jira] [Commented] (HBASE-9116) Add a view/edit tool for favored node mappings for regions

2013-08-26 Thread Jimmy Xiang (JIRA)

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

Jimmy Xiang commented on HBASE-9116:


Why updateFavoredNodes takes an OpenRegionRequest? 

{noformat}
+  public UpdateFavoredNodesResponse updateFavoredNodes(RpcController 
controller,
+  OpenRegionRequest request) throws ServiceException {
{noformat}

 Add a view/edit tool for favored node mappings for regions
 --

 Key: HBASE-9116
 URL: https://issues.apache.org/jira/browse/HBASE-9116
 Project: HBase
  Issue Type: Improvement
  Components: Region Assignment
Affects Versions: 0.95.0
Reporter: Devaraj Das
Assignee: Devaraj Das
 Fix For: 0.96.0

 Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, 
 9116-3.txt, 9116-4.txt


 Add a tool that one can run offline to view the favored node mappings for 
 regions, and also fix the mappings if needed. Such a tool exists in the 
 0.89-fb branch. Will port it over to trunk/0.95.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9116) Add a view/edit tool for favored node mappings for regions

2013-08-26 Thread Jimmy Xiang (JIRA)

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

Jimmy Xiang commented on HBASE-9116:


Is the hbase-site.xml change intentional?

 Add a view/edit tool for favored node mappings for regions
 --

 Key: HBASE-9116
 URL: https://issues.apache.org/jira/browse/HBASE-9116
 Project: HBase
  Issue Type: Improvement
  Components: Region Assignment
Affects Versions: 0.95.0
Reporter: Devaraj Das
Assignee: Devaraj Das
 Fix For: 0.96.0

 Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, 
 9116-3.txt, 9116-4.txt


 Add a tool that one can run offline to view the favored node mappings for 
 regions, and also fix the mappings if needed. Such a tool exists in the 
 0.89-fb branch. Will port it over to trunk/0.95.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9307) HalfStoreFileReader needs to handle the faked key else compactions go into infinite loops

2013-08-26 Thread Jean-Daniel Cryans (JIRA)

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

Jean-Daniel Cryans commented on HBASE-9307:
---

I kept the parent and daughter regions that trigger the error, simply untar and 
run the CompactionTool on the table's folder: 
https://people.apache.org/~jdcryans/testtable.tar.gz

 HalfStoreFileReader needs to handle the faked key else compactions go into 
 infinite loops
 -

 Key: HBASE-9307
 URL: https://issues.apache.org/jira/browse/HBASE-9307
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Jean-Daniel Cryans
Assignee: Jean-Daniel Cryans
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9307.patch


 I found this while trying out 0.95.2
 I couldn't shut my cluster down because one region was still compacting, but 
 it already had been doing that for an hour and it only had 80MBs of data.
 Debugging I saw that it was a post-split compaction, specifically for the top 
 part of the HFiles, and that it was just spinning on the first entry in the 
 file.
 Eventually I saw that the anonymous HFileScanner inside 
 HalfStoreFileReader.getScanner (that's so dirty) wasn't handling 
 HConstants.INDEX_KEY_MAGIC in seekTo() when calling this:
 bq. this.delegate.seekTo(splitkey)
 Instead it would treat this as if the split key wasn't in the file, but still 
 seek back to the beginning of the file *then read on from there*.
 During the compaction it would see a KV that's not even part of the region, 
 and it just tries to find the correct block over and over again.
 This came from HBASE-7845.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HBASE-9338) Test Big Linked List fails on Hadoop 2.1.0

2013-08-26 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-9338:


 Summary: Test Big Linked List fails on Hadoop 2.1.0
 Key: HBASE-9338
 URL: https://issues.apache.org/jira/browse/HBASE-9338
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9217) TestReplicationSmallTests#testDisableEnable fails intermittently

2013-08-26 Thread Jean-Daniel Cryans (JIRA)

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

Jean-Daniel Cryans commented on HBASE-9217:
---

Did you see it failing again?

 TestReplicationSmallTests#testDisableEnable fails intermittently
 

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

 Attachments: 9217-v1.txt, 9217-v2.txt, 9217-v3.txt, 
 testDisableEnable.txt


 From 
 https://builds.apache.org/job/HBase-0.95/444/testReport/junit/org.apache.hadoop.hbase.replication/TestReplicationSmallTests/testDisableEnable/
  :
 {code}
 java.lang.AssertionError: Waited too much time for put replication
   at org.junit.Assert.fail(Assert.java:88)
   at 
 org.apache.hadoop.hbase.replication.TestReplicationSmallTests.testDisableEnable(TestReplicationSmallTests.java:313)
 ...
 2013-08-14 08:06:47,228 DEBUG 
 [RS:1;vesta:39079-EventThread.replicationSource,2] 
 wal.ProtobufLogReader(118): After reading the trailer: walEditsStopOffset: 0, 
 fileLength: 0, trailerPresent: false
 2013-08-14 08:06:47,228 WARN  
 [RS:1;vesta:39079-EventThread.replicationSource,2] 
 regionserver.ReplicationSource(301): 2 Got: 
 java.io.IOException: Cannot seek after EOF
   at 
 org.apache.hadoop.hdfs.DFSClient$DFSInputStream.seek(DFSClient.java:2593)
   at 
 org.apache.hadoop.fs.FSDataInputStream.seek(FSDataInputStream.java:37)
   at 
 org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader.seekOnFs(ProtobufLogReader.java:275)
   at 
 org.apache.hadoop.hbase.regionserver.wal.ReaderBase.seek(ReaderBase.java:115)
   at 
 org.apache.hadoop.hbase.replication.regionserver.ReplicationHLogReaderManager.seek(ReplicationHLogReaderManager.java:108)
   at 
 org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.readAllEntriesToReplicateOrNextFile(ReplicationSource.java:388)
   at 
 org.apache.hadoop.hbase.replication.regionserver.ReplicationSource.run(ReplicationSource.java:297)
 2013-08-14 08:06:47,228 DEBUG 
 [RS:1;vesta:39079-EventThread.replicationSource,2] 
 regionserver.ReplicationSource(578): Nothing to replicate, sleeping 100 times 
 1
 2013-08-14 08:06:47,329 DEBUG 
 [RS:1;vesta:39079-EventThread.replicationSource,2] 
 fs.HFileSystem$ReorderWALBlocks(327): 
 /user/jenkins/hbase/WALs/vesta.apache.org,39079,1376467506138/vesta.apache.org%2C39079%2C1376467506138.1376467603252
  is an HLog file, so reordering blocks, last hostname will be:vesta.apache.org
 {code}
 Looking at test output from successful builds, I didn't see the above 
 exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9286) ageOfLastShippedOp replication metric doesn't update if the slave regionserver is stalled

2013-08-26 Thread Jean-Daniel Cryans (JIRA)

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

Jean-Daniel Cryans commented on HBASE-9286:
---

Oh it's a 0.94 patch. Can you provide one for trunk, [~posix4e]?

 ageOfLastShippedOp replication metric doesn't update if the slave 
 regionserver is stalled
 -

 Key: HBASE-9286
 URL: https://issues.apache.org/jira/browse/HBASE-9286
 Project: HBase
  Issue Type: Bug
Reporter: Alex Newman
Assignee: Alex Newman
 Attachments: 
 0001-HBASE-9286.-ageOfLastShippedOp-replication-metric-do.patch


 In replicationmanager
  HRegionInterface rrs = getRS();
 rrs.replicateLogEntries(Arrays.copyOf(this.entriesArray, 
 currentNbEntries));
 
 this.metrics.setAgeOfLastShippedOp(
 this.entriesArray[currentNbEntries-1].getKey().getWriteTime());
 break;
 which makes sense, but is wrong. The problem is that rrs.replicateLogEntries 
 will block for a very long time if the slave server is suspended or 
 unavailable but not down.
 However this is easy to fix. We just need to call   
 refreshAgeOfLastShippedOp();
 on a regular basis, in a different thread. I've attached a patch which fixed 
 this for cdh4. I can make one for trunk and the like as well if you need me 
 to do but it's a small change.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9278) Reading Pre-namespace meta table edits kills the reader

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9278:
--

So far so good.  A test would be ok in here though I'd say... an old wal edit 
w/ root/meta in it and ensure that new one has new tablename refs.

 Reading Pre-namespace meta table edits kills the reader
 ---

 Key: HBASE-9278
 URL: https://issues.apache.org/jira/browse/HBASE-9278
 Project: HBase
  Issue Type: Bug
  Components: migration, wal
Affects Versions: 0.95.2
Reporter: Himanshu Vashishtha
Assignee: Himanshu Vashishtha
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: HBase-9278-v0.patch


 In upgrading to 0.96, there might be some meta/root table edits. Currently, 
 we are just killing SplitLogWorker thread in case it sees any META, or ROOT 
 waledit, which blocks log splitting/replaying of remaining WALs.
 {code}
 2013-08-20 15:45:16,998 ERROR regionserver.SplitLogWorker 
 (SplitLogWorker.java:run(210)) - unexpected error 
 java.lang.IllegalArgumentException: .META. no longer exists. The table has 
 been renamed to hbase:meta
 at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:269)
 at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:261)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogKey.readFields(HLogKey.java:338)
 at 
 org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1898)
 at 
 org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1938)
 at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.readNext(SequenceFileLogReader.java:215)
 at 
 org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:98)
 at 
 org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:85)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getNextLogLine(HLogSplitter.java:582)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:292)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:209)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker$1.exec(SplitLogWorker.java:138)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker.grabTask(SplitLogWorker.java:358)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker.taskLoop(SplitLogWorker.java:245)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker.run(SplitLogWorker.java:205)
 at java.lang.Thread.run(Thread.java:662)
 2013-08-20 15:45:16,999 INFO  regionserver.SplitLogWorker 
 (SplitLogWorker.java:run(212)) - SplitLogWorker localhost,60020,1377035111898 
 exiting
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-6581) Build with hadoop.profile=3.0

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-6581:
--

Would be good if you could come closer in to its implemented name (this is good 
on history http://blog.cloudera.com/blog/2009/07/file-appends-in-hdfs/).  
hflush is take?  hsync is taken?

 Build with hadoop.profile=3.0
 -

 Key: HBASE-6581
 URL: https://issues.apache.org/jira/browse/HBASE-6581
 Project: HBase
  Issue Type: Bug
Reporter: Eric Charles
Assignee: Eric Charles
 Attachments: HBASE-6581-1.patch, HBASE-6581-20130821.patch, 
 HBASE-6581-2.patch, HBASE-6581-3.patch, HBASE-6581.diff, HBASE-6581.diff


 Building trunk with hadoop.profile=3.0 gives exceptions (see [1]) due to 
 change in the hadoop maven modules naming (and also usage of 3.0-SNAPSHOT 
 instead of 3.0.0-SNAPSHOT in hbase-common).
 I can provide a patch that would move most of hadoop dependencies in their 
 respective profiles and will define the correct hadoop deps in the 3.0 
 profile.
 Please tell me if that's ok to go this way.
 Thx, Eric
 [1]
 $ mvn clean install -Dhadoop.profile=3.0
 [INFO] Scanning for projects...
 [ERROR] The build could not read 3 projects - [Help 1]
 [ERROR]   
 [ERROR]   The project org.apache.hbase:hbase-server:0.95-SNAPSHOT 
 (/d/hbase.svn/hbase-server/pom.xml) has 3 errors
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-common:jar is missing. @ line 655, column 21
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-annotations:jar is missing. @ line 659, column 21
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-minicluster:jar is missing. @ line 663, column 21
 [ERROR]   
 [ERROR]   The project org.apache.hbase:hbase-common:0.95-SNAPSHOT 
 (/d/hbase.svn/hbase-common/pom.xml) has 3 errors
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-common:jar is missing. @ line 170, column 21
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-annotations:jar is missing. @ line 174, column 21
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-minicluster:jar is missing. @ line 178, column 21
 [ERROR]   
 [ERROR]   The project org.apache.hbase:hbase-it:0.95-SNAPSHOT 
 (/d/hbase.svn/hbase-it/pom.xml) has 3 errors
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-common:jar is missing. @ line 220, column 18
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-annotations:jar is missing. @ line 224, column 21
 [ERROR] 'dependencies.dependency.version' for 
 org.apache.hadoop:hadoop-minicluster:jar is missing. @ line 228, column 21
 [ERROR] 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-8549) Integrate Favored Nodes into StochasticLoadBalancer

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-8549:
--

IMO, favorednodes should be aspect of stochastic rather than distinct balancer. 
 Few will be those who would want a balancer that only considered one attribute 
and fewer again will be those who will actually change the config.  Might be 
good enough for 0.96 though; i.e. asking folks to explicitly enable this new 
experiemental feature.

 Integrate Favored Nodes into StochasticLoadBalancer
 ---

 Key: HBASE-8549
 URL: https://issues.apache.org/jira/browse/HBASE-8549
 Project: HBase
  Issue Type: Bug
  Components: Balancer
Affects Versions: 0.98.0, 0.95.1
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-8549-0.patch


 Right now we have a FavoredNodeLoadBalancer.  It would be pretty easy to 
 integrate the favored node list into the strochastic balancer.  Then we would 
 have the best of both worlds.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9333) hbase.hconnection.threads.max should not be configurable else you get RejectedExecutionException

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9333:
--

It should be possible to set an upper bound though?  Is the executor 
misconfigured such that it can't be capped at an upper limit?

 hbase.hconnection.threads.max should not be configurable else you get 
 RejectedExecutionException
 

 Key: HBASE-9333
 URL: https://issues.apache.org/jira/browse/HBASE-9333
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.95.2
Reporter: Jean-Daniel Cryans
 Fix For: 0.98.0, 0.96.0


 Trying to set hbase.hconnection.threads.max to a lower number than its 
 default of Integer.MAX_VALUE simply results in a RejectedExecutionException 
 when the max is reached. It seems there's no good reason to keep this 
 configurable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9338) Test Big Linked List fails on Hadoop 2.1.0

2013-08-26 Thread stack (JIRA)

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

stack updated HBASE-9338:
-

Priority: Critical  (was: Major)

This is critical if not a blocker I'd say.

 Test Big Linked List fails on Hadoop 2.1.0
 --

 Key: HBASE-9338
 URL: https://issues.apache.org/jira/browse/HBASE-9338
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Critical
 Fix For: 0.96.0




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9338) Test Big Linked List fails on Hadoop 2.1.0

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark commented on HBASE-9338:
--

Configs on the cluster:

core-site.xml
{code}
?xml version=1.0?
?xml-stylesheet type=text/xsl href=configuration.xsl?

!-- Put site-specific property overrides in this file. --

configuration

  property
namefs.default.name/name
valuehdfs://${MASTER_HOSTNAME}:8020//value
  /property

  property
namehadoop.data.dir0/name
value/data0//value
  /property

  property
namehadoop.data.dir1/name
value/data1//value
  /property

  property
namehadoop.data.dir2/name
value/data2//value
  /property

  property
namehadoop.data.dir3/name
value/data3//value
  /property

  property
namehadoop.data.dir4/name
value/data4//value
  /property

  property
namehadoop.data.dir5/name
value/data5//value
  /property

  property
namemapred.temp.dir/name
value${hadoop.data.dir1}/mapred/temp/value
descriptionA shared directory for temporary files.
/description
  /property

  property
nameipc.client.connect.timeout/name
value1000/value
  /property

  property
nameipc.client.connect.max.retries.on.timeouts/name
value2/value
  /property

  property
namedfs.socket.timeout/name
value5000/value
  /property

  property
namedfs.socket.write.timeout/name
value5000/value
  /property

  property
nameipc.ping.interval/name
value2/value
  /property

  property
nameio.file.buffer.size/name
value65536/value
  /property

  property
nameipc.client.connect.max.retries/name
value10/value
  /property

  property
nameipc.client.tcpnodelay/name
valuetrue/value
  /property

  property
nameipc.server.tcpnodelay/name
valuetrue/value
  /property

  property
namedfs.domain.socket.path/name
value/var/lib/hadoop/dn_socket._PORT/value
  /property
  
  property
namedfs.client.read.shortcircuit/name
valuetrue/value
  /property

  property
namedfs.client.file-block-storage-locations.timeout/name
value3000/value
  /property

  property
 namedfs.client.read.shortcircuit.skip.checksum/name
 valuetrue/value
   /property

/configuration
{code}

hdfs-site.xml
{code}
?xml version=1.0?
?xml-stylesheet type=text/xsl href=configuration.xsl?
configuration

  property
namedfs.datanode.handler.count/name
!-- default 10 --
value32/value
descriptionThe number of server threads for the
datanode./description
  /property

  property
namedfs.namenode.handler.count/name
!-- default 10 --
value32/value
descriptionThe number of server threads for the
namenode./description
  /property

  property
namedfs.block.size/name
value134217728/value
descriptionThe default block size for new files./description
  /property

  property
namedfs.datanode.max.xcievers/name
value4098/value
  /property

  property
namedfs.namenode.replication.interval/name
value15/value
  /property

  property
namedfs.balance.bandwidthPerSec/name
value10485760/value
  /property

  property
namefs.checkpoint.dir/name
value${hadoop.data.dir1}/dfs/namesecondary/value
  /property

  property
namedfs.name.dir/name
value${hadoop.data.dir0}/dfs/name/value
  /property

  property
namedfs.data.dir/name

value${hadoop.data.dir0}/dfs/data,${hadoop.data.dir1}/dfs/data,${hadoop.data.dir2}/dfs/data,${hadoop.data.dir3}/dfs/data,${hadoop.data.dir4}/dfs/data,${hadoop.data.dir5}/dfs/data/value
  /property

  property
namedfs.datanode.socket.write.timeout/name
value1/value
  /property

  property
nameipc.client.connect.timeout/name
value1000/value
  /property

  property
nameipc.client.connect.max.retries.on.timeouts/name
value2/value
  /property

  property
namedfs.socket.timeout/name
value5000/value
  /property

  property
namedfs.socket.write.timeout/name
value5000/value
  /property

  property
namedfs.domain.socket.path/name
value/var/lib/hadoop/dn_socket._PORT/value
  /property

  property
namedfs.block.local-path-access.user/name
valuehbase/value
  /property

  property
 namedfs.client.read.shortcircuit.skip.checksum/name
 valuetrue/value
   /property

  property
namedfs.client.file-block-storage-locations.timeout/name
value3000/value
  /property

/configuration
{code}

yarn-site.xml:
{code}
?xml version=1.0?
configuration
  property
nameyarn.nodemanager.aux-services/name
valuemapreduce.shuffle/value
  /property
  property
nameyarn.nodemanager.aux-services.mapreduce.shuffle.class/name
valueorg.apache.hadoop.mapred.ShuffleHandler/value
  /property
  property
nameyarn.resourcemanager.address/name
value${MASTER_HOSTNAME}:10040/value
descriptionIn Server specified the port that Resource Manager will runn 
on. In 

[jira] [Updated] (HBASE-9299) Generate the protobuf classes with hadoop-maven-plugin

2013-08-26 Thread stack (JIRA)

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

stack updated HBASE-9299:
-

Fix Version/s: 0.96.0
   0.98.0
 Assignee: Eric Charles
 Hadoop Flags: Reviewed
   Status: Patch Available  (was: Open)

Running by hadoopqa.

 Generate the protobuf classes with hadoop-maven-plugin
 --

 Key: HBASE-9299
 URL: https://issues.apache.org/jira/browse/HBASE-9299
 Project: HBase
  Issue Type: New Feature
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9299.patch


 For now, the protobuf classes are generated once by a dev, and put in 
 src/main/resouce. 
 This allows the other dev to not have the correct protoc version available on 
 their machine. However, when a dev wants to modify the protoc messages, he 
 has to know how to generate the classes. This could be documented...
 Another approach would be to put a harder requirement on the hbase developers 
 (protoc available) and let the hadoop-maven-plugin 
 (http://central.maven.org/maven2/org/apache/hadoop/hadoop-maven-plugins/2.0.5-alpha)
  to do the work (I have bad experience with other maven protobuf plugins, the 
 hadoop one works just out of the box).
 I don't think asking to install protoc to build hbase is so difficult, but 
 that's an additional step between the dev and the artifcat.
 The advantage would be to allow to have different protobuf versions for 
 different hbase distributions (perfectly possible but quite theorical).
 So
 option 1: We are happy to keep the classes in src/main/java
 option 2: We want to move to hadoop-maven-plugin 
 option 3: I may be short of idea... any other input?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9116) Add a view/edit tool for favored node mappings for regions

2013-08-26 Thread Jimmy Xiang (JIRA)

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

Jimmy Xiang commented on HBASE-9116:


Can we create a similar putsToMetaTable method which takes a conf in 
MetaEditor?  We need to handle exceptions and close the table at the end.
{noformat}
-MetaEditor.putsToMetaTable(catalogTracker, puts);
+// Write the region assignments to the meta table.
+HTable metaTable = new HTable(conf, TableName.META_TABLE_NAME);
+metaTable.put(puts);
{noformat}

 Add a view/edit tool for favored node mappings for regions
 --

 Key: HBASE-9116
 URL: https://issues.apache.org/jira/browse/HBASE-9116
 Project: HBase
  Issue Type: Improvement
  Components: Region Assignment
Affects Versions: 0.95.0
Reporter: Devaraj Das
Assignee: Devaraj Das
 Fix For: 0.96.0

 Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, 
 9116-3.txt, 9116-4.txt


 Add a tool that one can run offline to view the favored node mappings for 
 regions, and also fix the mappings if needed. Such a tool exists in the 
 0.89-fb branch. Will port it over to trunk/0.95.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9281) user_permission command encounters NullPointerException

2013-08-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-9281:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12599979/9281.addendum
  against trunk revision .

{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 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

{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:red}-1 release audit{color}.  The applied patch generated 2 release 
audit warnings (more than the trunk's current 0 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/6898//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6898//console

This message is automatically generated.

 user_permission command encounters NullPointerException
 ---

 Key: HBASE-9281
 URL: https://issues.apache.org/jira/browse/HBASE-9281
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Ted Yu
Assignee: Ted Yu
 Attachments: 9281.addendum, 9281-v1.txt


 As user hbase, user_permission command gave:
 {code}
 java.io.IOException: java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2147)
   ... 1 more
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
 

[jira] [Commented] (HBASE-9338) Test Big Linked List fails on Hadoop 2.1.0

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark commented on HBASE-9338:
--

Here's the command run:
{code}
hbase org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList Loop 5 12 
250 IntegrationTestBigLinkedList 10
{code}

And the result:
{code}
org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList$Verify$Counts
REFERENCED=11520689
UNREFERENCED=11520770
File Input Format Counters 
Bytes Read=0
File Output Format Counters 
Bytes Written=972064362
2013-08-26 11:48:03,060 INFO  [main] hbase.HBaseCluster: Added new HBaseAdmin
2013-08-26 11:48:03,061 ERROR [main] util.AbstractHBaseTool: Error running 
command-line tool
java.lang.RuntimeException: Verify.run failed with return code: 1
at 
org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList$Loop.runVerify(IntegrationTestBigLinkedList.java:726)
at 
org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList$Loop.run(IntegrationTestBigLinkedList.java:764)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at 
org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList.runTestFromCommandLine(IntegrationTestBigLinkedList.java:1063)
at 
org.apache.hadoop.hbase.IntegrationTestBase.doWork(IntegrationTestBase.java:77)
at 
org.apache.hadoop.hbase.util.AbstractHBaseTool.run(AbstractHBaseTool.java:112)
at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70)
at 
org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList.main(IntegrationTestBigLinkedList.java:1098){code}


 Test Big Linked List fails on Hadoop 2.1.0
 --

 Key: HBASE-9338
 URL: https://issues.apache.org/jira/browse/HBASE-9338
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Critical
 Fix For: 0.96.0




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9329) SnapshotManager should check for directory existance before throwing a warning.

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9329:
---

SUCCESS: Integrated in HBase-0.94-security #271 (See 
[https://builds.apache.org/job/HBase-0.94-security/271/])
HBASE-9329 SnapshotManager should check for directory existance before throwing 
a warning (Jean-Marc Spaggiari) (mbertozzi: rev 1517609)
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotManager.java


 SnapshotManager should check for directory existance before throwing a 
 warning.
 ---

 Key: HBASE-9329
 URL: https://issues.apache.org/jira/browse/HBASE-9329
 Project: HBase
  Issue Type: Bug
  Components: snapshots
Affects Versions: 0.98.0, 0.95.2, 0.94.11
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Trivial
 Fix For: 0.98.0, 0.95.2, 0.94.12

 Attachments: HBASE-9329-v0-trunk.patch


 {quote}
 2013-08-23 17:57:24,277 WARN 
 org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete 
 working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
 {quote}
 I don't have any .hbase-snapshot directory, so there is no need to try to 
 delete the .tmp directory into it. Might first need to check if this 
 directory exist.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9333) hbase.hconnection.threads.max should not be configurable else you get RejectedExecutionException

2013-08-26 Thread Jean-Daniel Cryans (JIRA)

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

Jean-Daniel Cryans commented on HBASE-9333:
---

The executor is using a direct handoff approach which can't be capped yeah. 
This is not different than 0.94, but we were using less threads back then.

 hbase.hconnection.threads.max should not be configurable else you get 
 RejectedExecutionException
 

 Key: HBASE-9333
 URL: https://issues.apache.org/jira/browse/HBASE-9333
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.95.2
Reporter: Jean-Daniel Cryans
 Fix For: 0.98.0, 0.96.0


 Trying to set hbase.hconnection.threads.max to a lower number than its 
 default of Integer.MAX_VALUE simply results in a RejectedExecutionException 
 when the max is reached. It seems there's no good reason to keep this 
 configurable.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HBASE-9339) Make HBase revision GIT aware.

2013-08-26 Thread Elliott Clark (JIRA)
Elliott Clark created HBASE-9339:


 Summary: Make HBase revision GIT aware.
 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark


Many developers are using git to work with HBase.  We should make the build 
scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9116) Add a view/edit tool for favored node mappings for regions

2013-08-26 Thread Jimmy Xiang (JIRA)

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

Jimmy Xiang commented on HBASE-9116:


I see several places warning is logged like this:
{noformat}
+LOG.warn(Cannot place the favored nodes for region 
++ regionInfo.getRegionNameAsString() +  because  + e);
{noformat}
Perhaps, it is better to log the stack trace as well:
{noformat}
+LOG.warn(Cannot place the favored nodes for region 
++ regionInfo.getRegionNameAsString() +  because  + e, e);
{noformat}

Some function may not throw exception declared, for example, 
FavoredNodeAssignmentHelper#placeSecondaryAndTertiaryWithRestrictions doesn't 
throw IOException.

Good stuff.  Is this still WIP? How can we use this?  Edit the meta table from 
hbase shell?

 Add a view/edit tool for favored node mappings for regions
 --

 Key: HBASE-9116
 URL: https://issues.apache.org/jira/browse/HBASE-9116
 Project: HBase
  Issue Type: Improvement
  Components: Region Assignment
Affects Versions: 0.95.0
Reporter: Devaraj Das
Assignee: Devaraj Das
 Fix For: 0.96.0

 Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, 
 9116-3.txt, 9116-4.txt


 Add a tool that one can run offline to view the favored node mappings for 
 regions, and also fix the mappings if needed. Such a tool exists in the 
 0.89-fb branch. Will port it over to trunk/0.95.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HBASE-9340) revoke 'user' throws ArrayIndexOutOfBoundsException

2013-08-26 Thread Matteo Bertozzi (JIRA)
Matteo Bertozzi created HBASE-9340:
--

 Summary: revoke 'user' throws ArrayIndexOutOfBoundsException
 Key: HBASE-9340
 URL: https://issues.apache.org/jira/browse/HBASE-9340
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0
 Attachments: HBASE-9340-v0.patch

Trying to revoke a global rights throws
{code}
hbase(main):004:0 revoke 'test'
Java::JavaLang::ArrayIndexOutOfBoundsException: 3
{code}
The problem is that jruby is not able to do the bind with revoke(..., 
Permission.Action... actions)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9340) revoke 'user' throws ArrayIndexOutOfBoundsException

2013-08-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-9340:
---

Attachment: HBASE-9340-v0.patch

 revoke 'user' throws ArrayIndexOutOfBoundsException
 ---

 Key: HBASE-9340
 URL: https://issues.apache.org/jira/browse/HBASE-9340
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9340-v0.patch


 Trying to revoke a global rights throws
 {code}
 hbase(main):004:0 revoke 'test'
 Java::JavaLang::ArrayIndexOutOfBoundsException: 3
 {code}
 The problem is that jruby is not able to do the bind with revoke(..., 
 Permission.Action... actions)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9340) revoke 'user' throws ArrayIndexOutOfBoundsException

2013-08-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-9340:
---

Status: Patch Available  (was: Open)

 revoke 'user' throws ArrayIndexOutOfBoundsException
 ---

 Key: HBASE-9340
 URL: https://issues.apache.org/jira/browse/HBASE-9340
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9340-v0.patch


 Trying to revoke a global rights throws
 {code}
 hbase(main):004:0 revoke 'test'
 Java::JavaLang::ArrayIndexOutOfBoundsException: 3
 {code}
 The problem is that jruby is not able to do the bind with revoke(..., 
 Permission.Action... actions)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9213) create a unified shim for hadoop 1 and 2 so that there's one build of HBase

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9213:
--

If we did what hive did, questions:

1. We would complicate the simple case, running hbase standalone (Download 
hbase binary, if hadoop 1.x.x, copy jars a, b, c to lib, if hadoop 2.x.x, copy 
jars d, e, f.  Do not copy hadoop 0.20 jars because we do not work unless you 
 and so on).  We already get dinged on being complicated.  We would be 
raising the bar for the folks who just want to try it out.
2. How do the hive shims work?  Is it download hive, put in place the 
hive-hadoop-2 shim, and then add in hadoop2?  Or is it download hive and put in 
place hadoop2 (and hive will figure via reflection what it has under it and 
then invoke the approriate hadoop1 or hadoop2 method?).  If the former, that is 
what we have now (our shims are called hbase-hadoop*-compat).  If the latter 
case, then IIUC, it would be untenable us doing reflection to figure if hadoop 
metrics1 or hadoop metrics2 and then per metric, make the appropriate 
invocation; we'd make a horrid reflection spaghetti.

Maybe we could have a setup script where you say what you want to run against 
and we then go fetch what we need (including compat modules from maven) and 
then you start hbase (this'd work for standalone mode but then how to 
distinguish from actual install-on-a-cluster)

1. This is basically still correct for building different tgzs 
http://hbase.apache.org/book.html#build (I need to update)
4. Hard thing about another build tool is that in the end we have to publish to 
a maven repo somehow; we could have a build tool and then have another script 
to do maven publish (and I'm wary that all is fixed if you just use this other 
build tool -- heard that one before).



 create a unified shim for hadoop 1 and 2 so that there's one build of HBase
 ---

 Key: HBASE-9213
 URL: https://issues.apache.org/jira/browse/HBASE-9213
 Project: HBase
  Issue Type: Brainstorming
  Components: build
Reporter: Sergey Shelukhin

 This is a brainstorming JIRA. Working with HBase dependency at this point 
 seems to be rather painful from what I hear from other folks. We could do the 
 hive model with unified shim, built in such manner that it can work with 
 either version, where at build time dependencies for all 2-3 versions are 
 pulled and the appropriate one is used for tests, and when running HBase you 
 have to point at Hadoop directory to get the dependencies. I am not very 
 proficient at maven so not quite certain of the best solution yet.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9340) revoke 'user' throws ArrayIndexOutOfBoundsException

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9340:
--

+1 if works for you M

 revoke 'user' throws ArrayIndexOutOfBoundsException
 ---

 Key: HBASE-9340
 URL: https://issues.apache.org/jira/browse/HBASE-9340
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9340-v0.patch


 Trying to revoke a global rights throws
 {code}
 hbase(main):004:0 revoke 'test'
 Java::JavaLang::ArrayIndexOutOfBoundsException: 3
 {code}
 The problem is that jruby is not able to do the bind with revoke(..., 
 Permission.Action... actions)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-9332:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12599976/0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch
  against trunk revision .

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

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

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

{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:red}-1 release audit{color}.  The applied patch generated 2 release 
audit warnings (more than the trunk's current 0 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.TestFullLogReconstruction

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6899//console

This message is automatically generated.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails

2013-08-26 Thread stack (JIRA)

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

stack updated HBASE-9023:
-

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

Resolving fixed.  This used to fail frequently but looks like Ted fixed it.

 TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
 

 Key: HBASE-9023
 URL: https://issues.apache.org/jira/browse/HBASE-9023
 Project: HBase
  Issue Type: Bug
Reporter: stack
Assignee: Ted Yu
 Fix For: 0.98.0, 0.96.0

 Attachments: 9023.addendum1, 9023-v1.txt


 Any one want to take a look at this one? 
 https://builds.apache.org/job/HBase-TRUNK/4283/testReport/org.apache.hadoop.hbase/TestIOFencing/testFencingAroundCompactionAfterWALSync/
 {code}
 java.lang.AssertionError
   at org.junit.Assert.fail(Assert.java:86)
   at org.junit.Assert.assertTrue(Assert.java:41)
   at org.junit.Assert.assertTrue(Assert.java:52)
   at org.apache.hadoop.hbase.TestIOFencing.doTest(TestIOFencing.java:263)
   at 
 org.apache.hadoop.hbase.TestIOFencing.testFencingAroundCompactionAfterWALSync(TestIOFencing.java:217)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
   at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
   at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
   at org.junit.runners.Suite.runChild(Suite.java:127)
   at org.junit.runners.Suite.runChild(Suite.java:26)
   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
   at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
   at java.lang.Thread.run(Thread.java:662)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (HBASE-8889) TestIOFencing#testFencingAroundCompaction occasionally fails

2013-08-26 Thread stack (JIRA)

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

stack resolved HBASE-8889.
--

Resolution: Duplicate

Resolving as dup of HBASE-9023 as per Ted.

 TestIOFencing#testFencingAroundCompaction occasionally fails
 

 Key: HBASE-8889
 URL: https://issues.apache.org/jira/browse/HBASE-8889
 Project: HBase
  Issue Type: Test
Reporter: Ted Yu
Priority: Minor

 From 
 https://builds.apache.org/job/PreCommit-HBASE-Build/6232//testReport/org.apache.hadoop.hbase/TestIOFencing/testFencingAroundCompaction/
  :
 {code}
 java.lang.AssertionError: Timed out waiting for new server to open region
   at org.junit.Assert.fail(Assert.java:88)
   at org.junit.Assert.assertTrue(Assert.java:41)
   at org.apache.hadoop.hbase.TestIOFencing.doTest(TestIOFencing.java:269)
   at 
 org.apache.hadoop.hbase.TestIOFencing.testFencingAroundCompaction(TestIOFencing.java:205)
 {code}
 {code}
 2013-07-06 23:13:53,120 INFO  [pool-1-thread-1] hbase.TestIOFencing(266): 
 Waiting for the new server to pick up the region 
 tabletest,,1373152125442.6e62d3b24ea23160931362b60359ff03.
 2013-07-06 23:13:54,120 INFO  [pool-1-thread-1] hbase.TestIOFencing(266): 
 Waiting for the new server to pick up the region 
 tabletest,,1373152125442.6e62d3b24ea23160931362b60359ff03.
 2013-07-06 23:13:55,121 DEBUG [pool-1-thread-1] 
 hbase.TestIOFencing$CompactionBlockerRegion(102): allowing compactions
 2013-07-06 23:13:55,121 INFO  [pool-1-thread-1] 
 hbase.HBaseTestingUtility(911): Shutting down minicluster
 2013-07-06 23:13:55,121 DEBUG [pool-1-thread-1] util.JVMClusterUtil(237): 
 Shutting down HBase Cluster
 2013-07-06 23:13:55,121 INFO  
 [RS:0;asf002:39065-smallCompactions-1373152134716] regionserver.HStore(951): 
 Starting compaction of 2 file(s) in family of 
 tabletest,,1373152125442.6e62d3b24ea23160931362b60359ff03. into 
 tmpdir=hdfs://localhost:50140/user/jenkins/hbase/tabletest/6e62d3b24ea23160931362b60359ff03/.tmp,
  totalSize=108.4k
 ...
 2013-07-06 23:13:55,155 INFO  [RS:0;asf002:39065] 
 regionserver.HRegionServer(2476): Received CLOSE for the region: 
 6e62d3b24ea23160931362b60359ff03 ,which we are already trying to CLOSE
 2013-07-06 23:13:55,157 WARN  [RS:0;asf002:39065] 
 regionserver.HRegionServer(2414): Failed to close 
 tabletest,,1373152125442.6e62d3b24ea23160931362b60359ff03. - ignoring and 
 continuing
 org.apache.hadoop.hbase.exceptions.NotServingRegionException: The region 
 6e62d3b24ea23160931362b60359ff03 was already closing. New CLOSE request is 
 ignored.
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegion(HRegionServer.java:2479)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.closeRegionIgnoreErrors(HRegionServer.java:2409)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.closeUserRegions(HRegionServer.java:2011)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:903)
   at 
 org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.runRegionServer(MiniHBaseCluster.java:158)
   at 
 org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.access$000(MiniHBaseCluster.java:110)
   at 
 org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer$1.run(MiniHBaseCluster.java:142)
   at java.security.AccessController.doPrivileged(Native Method)
   at javax.security.auth.Subject.doAs(Subject.java:337)
   at 
 org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1131)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.apache.hadoop.hbase.util.Methods.call(Methods.java:41)
   at org.apache.hadoop.hbase.security.User.call(User.java:420)
   at org.apache.hadoop.hbase.security.User.access$300(User.java:51)
   at 
 org.apache.hadoop.hbase.security.User$SecureHadoopUser.runAs(User.java:260)
   at 
 org.apache.hadoop.hbase.MiniHBaseCluster$MiniHBaseClusterRegionServer.run(MiniHBaseCluster.java:140)
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9326) ServerName is created using getLocalSocketAddress, breaks binding to the wildcard address

2013-08-26 Thread Jean-Daniel Cryans (JIRA)

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

Jean-Daniel Cryans commented on HBASE-9326:
---

It's HBASE-8640 that started passing that address in the ServerName, it used to 
be that we were just passing the hostname that we were resolving before that.

 ServerName is created using getLocalSocketAddress, breaks binding to the 
 wildcard address
 -

 Key: HBASE-9326
 URL: https://issues.apache.org/jira/browse/HBASE-9326
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Jean-Daniel Cryans
Priority: Critical
 Fix For: 0.98.0, 0.96.0


 In HBASE-8148 I added a way to bind to specific addresses, like 0.0.0.0, but 
 right now in 0.95/trunk the ServerName is created using getLocalSocketAddress 
 in RpcServer so 0.0.0.0 gets published in ZK.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-8640) ServerName in master may not initialize with the configured ipc address of hbase.master.ipc.address

2013-08-26 Thread Jean-Daniel Cryans (JIRA)

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

Jean-Daniel Cryans commented on HBASE-8640:
---

I wish I caught this jira before.

bq. ServerName in master may not initialize with the configured ipc address of 
hbase.master.ipc.address

This is by design. Since hbase.master.ipc.address can be 0.0.0.0, you 
definitely don't want to publish 0.0.0.0 in ZK.

 ServerName in master may not initialize with the configured ipc address of 
 hbase.master.ipc.address
 ---

 Key: HBASE-8640
 URL: https://issues.apache.org/jira/browse/HBASE-8640
 Project: HBase
  Issue Type: Bug
  Components: master
Reporter: rajeshbabu
Assignee: rajeshbabu
 Fix For: 0.98.0, 0.95.2, 0.94.9

 Attachments: HBASE-8640_94.patch, HBASE-8640.patch


 We are starting rpc server with default interface hostname or configured ipc 
 address
 {code}
 this.rpcServer = HBaseRPC.getServer(this,
   new Class?[]{HMasterInterface.class, HMasterRegionInterface.class},
 initialIsa.getHostName(), // This is bindAddress if set else it's 
 hostname
 initialIsa.getPort(),
 numHandlers,
 0, // we dont use high priority handlers in master
 conf.getBoolean(hbase.rpc.verbose, false), conf,
 0); // this is a DNC w/o high priority handlers
 {code}
 But we are initialzing servername with default hostname always master znode 
 also have this hostname.
 {code}
 String hostname = Strings.domainNamePointerToHostName(DNS.getDefaultHost(
   conf.get(hbase.master.dns.interface, default),
   conf.get(hbase.master.dns.nameserver, default)));
   ...
 this.serverName = new ServerName(hostname,
   this.isa.getPort(), System.currentTimeMillis());
 {code}
 If both default interface hostname and configured ipc address are not same 
 clients will get MasterNotRunningException.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9312) Lower StochasticLoadBalancer's default max run time

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-9312:
-

  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

 Lower StochasticLoadBalancer's default max run time 
 

 Key: HBASE-9312
 URL: https://issues.apache.org/jira/browse/HBASE-9312
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9312-0.patch


 Three things about the 1 minute it takes to decide if we want to balance or 
 not:
  - 1 minute is also the default socket timeout, so if you call balancer in 
 the shell you often get a SocketTimeoutException back. Bad user experience.
  - Elliott was telling me that we might not even need 1 minute to compute a 
 good balance anyways because of other improvements. I tested 30 seconds on a 
 badly balanced cluster and it worked well.
  - I personally think that 1 minute is too much time (Elliott disagrees).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9338) Test Big Linked List fails on Hadoop 2.1.0

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-9338:
-

Attachment: HBASE-9338-0.patch

Looks like hadoop has changed the way they will serialize a null byte array.  
Changed the test to use the empty byte array constant.

 Test Big Linked List fails on Hadoop 2.1.0
 --

 Key: HBASE-9338
 URL: https://issues.apache.org/jira/browse/HBASE-9338
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Critical
 Fix For: 0.96.0

 Attachments: HBASE-9338-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-8640) ServerName in master may not initialize with the configured ipc address of hbase.master.ipc.address

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-8640:
--

Is this the issue that made HBASE-9326 [~jdcryans]?

 ServerName in master may not initialize with the configured ipc address of 
 hbase.master.ipc.address
 ---

 Key: HBASE-8640
 URL: https://issues.apache.org/jira/browse/HBASE-8640
 Project: HBase
  Issue Type: Bug
  Components: master
Reporter: rajeshbabu
Assignee: rajeshbabu
 Fix For: 0.98.0, 0.95.2, 0.94.9

 Attachments: HBASE-8640_94.patch, HBASE-8640.patch


 We are starting rpc server with default interface hostname or configured ipc 
 address
 {code}
 this.rpcServer = HBaseRPC.getServer(this,
   new Class?[]{HMasterInterface.class, HMasterRegionInterface.class},
 initialIsa.getHostName(), // This is bindAddress if set else it's 
 hostname
 initialIsa.getPort(),
 numHandlers,
 0, // we dont use high priority handlers in master
 conf.getBoolean(hbase.rpc.verbose, false), conf,
 0); // this is a DNC w/o high priority handlers
 {code}
 But we are initialzing servername with default hostname always master znode 
 also have this hostname.
 {code}
 String hostname = Strings.domainNamePointerToHostName(DNS.getDefaultHost(
   conf.get(hbase.master.dns.interface, default),
   conf.get(hbase.master.dns.nameserver, default)));
   ...
 this.serverName = new ServerName(hostname,
   this.isa.getPort(), System.currentTimeMillis());
 {code}
 If both default interface hostname and configured ipc address are not same 
 clients will get MasterNotRunningException.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9338) Test Big Linked List fails on Hadoop 2.1.0

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9338:
--

+1

 Test Big Linked List fails on Hadoop 2.1.0
 --

 Key: HBASE-9338
 URL: https://issues.apache.org/jira/browse/HBASE-9338
 Project: HBase
  Issue Type: Bug
  Components: test
Affects Versions: 0.96.0
Reporter: Elliott Clark
Assignee: Elliott Clark
Priority: Critical
 Fix For: 0.96.0

 Attachments: HBASE-9338-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9283) Struct and StructIterator should properly handle trailing nulls

2013-08-26 Thread James Taylor (JIRA)

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

James Taylor commented on HBASE-9283:
-

+1, I like your new impl that keeps the null extension logic localized to 
Struct and StructIterator.

 Struct and StructIterator should properly handle trailing nulls
 ---

 Key: HBASE-9283
 URL: https://issues.apache.org/jira/browse/HBASE-9283
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 0001-HBASE-9283-Struct-trailing-null-handling.patch, 
 0001-HBASE-9283-Struct-trailing-null-handling.patch


 For a composite row key, Phoenix strips off trailing null columns values in 
 the row key. The reason this is important is that then new nullable row key 
 columns can be added to a schema without requiring any data upgrade to 
 existing rows. Otherwise, adding new row key columns to the end of a schema 
 becomes extremely cumbersome, as you'd need to delete all existing rows and 
 add them back with a row key that includes a null value.
 Rather than Phoenix needing to modify the iteration code everywhere (as 
 [~ndimiduk] outlined here: 
 https://issues.apache.org/jira/browse/HBASE-8693?focusedCommentId=13744499page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13744499),
  it'd be better if StructIterator handled this out-of-the-box. Otherwise, if 
 Phoenix has to specialize this, we'd lose the interop piece which is the 
 justification for switching our type system to this new one in the first 
 place.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-9339:
-

Component/s: build

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Reporter: Elliott Clark

 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark commented on HBASE-9339:
--

Seems like this must have gotten broken on the maven modularization.

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark

 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9278) Reading Pre-namespace meta table edits kills the reader

2013-08-26 Thread Himanshu Vashishtha (JIRA)

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

Himanshu Vashishtha commented on HBASE-9278:


Okay. Let me try to come up with a test.

 Reading Pre-namespace meta table edits kills the reader
 ---

 Key: HBASE-9278
 URL: https://issues.apache.org/jira/browse/HBASE-9278
 Project: HBase
  Issue Type: Bug
  Components: migration, wal
Affects Versions: 0.95.2
Reporter: Himanshu Vashishtha
Assignee: Himanshu Vashishtha
Priority: Critical
 Fix For: 0.98.0, 0.96.0

 Attachments: HBase-9278-v0.patch


 In upgrading to 0.96, there might be some meta/root table edits. Currently, 
 we are just killing SplitLogWorker thread in case it sees any META, or ROOT 
 waledit, which blocks log splitting/replaying of remaining WALs.
 {code}
 2013-08-20 15:45:16,998 ERROR regionserver.SplitLogWorker 
 (SplitLogWorker.java:run(210)) - unexpected error 
 java.lang.IllegalArgumentException: .META. no longer exists. The table has 
 been renamed to hbase:meta
 at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:269)
 at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:261)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogKey.readFields(HLogKey.java:338)
 at 
 org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1898)
 at 
 org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1938)
 at 
 org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.readNext(SequenceFileLogReader.java:215)
 at 
 org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:98)
 at 
 org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:85)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.getNextLogLine(HLogSplitter.java:582)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:292)
 at 
 org.apache.hadoop.hbase.regionserver.wal.HLogSplitter.splitLogFile(HLogSplitter.java:209)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker$1.exec(SplitLogWorker.java:138)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker.grabTask(SplitLogWorker.java:358)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker.taskLoop(SplitLogWorker.java:245)
 at 
 org.apache.hadoop.hbase.regionserver.SplitLogWorker.run(SplitLogWorker.java:205)
 at java.lang.Thread.run(Thread.java:662)
 2013-08-20 15:45:16,999 INFO  regionserver.SplitLogWorker 
 (SplitLogWorker.java:run(212)) - SplitLogWorker localhost,60020,1377035111898 
 exiting
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-9339:
-

Affects Version/s: 0.98.0
   0.95.2

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 0.98.0, 0.95.2
Reporter: Elliott Clark

 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-9339:
-

Summary: Fix saveVersion.sh's GIT awareness.  (was: Make HBase revision GIT 
aware.)

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
Reporter: Elliott Clark

 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9329) SnapshotManager should check for directory existance before throwing a warning.

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9329:
---

SUCCESS: Integrated in HBase-0.94 #1125 (See 
[https://builds.apache.org/job/HBase-0.94/1125/])
HBASE-9329 SnapshotManager should check for directory existance before throwing 
a warning (Jean-Marc Spaggiari) (mbertozzi: rev 1517609)
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotManager.java


 SnapshotManager should check for directory existance before throwing a 
 warning.
 ---

 Key: HBASE-9329
 URL: https://issues.apache.org/jira/browse/HBASE-9329
 Project: HBase
  Issue Type: Bug
  Components: snapshots
Affects Versions: 0.98.0, 0.95.2, 0.94.11
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Trivial
 Fix For: 0.98.0, 0.95.2, 0.94.12

 Attachments: HBASE-9329-v0-trunk.patch


 {quote}
 2013-08-23 17:57:24,277 WARN 
 org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete 
 working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
 {quote}
 I don't have any .hbase-snapshot directory, so there is no need to try to 
 delete the .tmp directory into it. Might first need to check if this 
 directory exist.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark updated HBASE-9339:
-

Attachment: HBASE-9339-0.patch

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 0.98.0, 0.95.2
Reporter: Elliott Clark
 Attachments: HBASE-9339-0.patch


 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread stack (JIRA)

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

stack commented on HBASE-9339:
--

+1 if it works for you 

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 0.98.0, 0.95.2
Reporter: Elliott Clark
 Attachments: HBASE-9339-0.patch


 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread stack (JIRA)

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

stack updated HBASE-9332:
-

  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Committed to 0.95 and trunk.  Thanks for the patch Nick.

 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-9337:
---

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

 shell 'user_permission' throws no method 'toStringBinary' for 
 (o.a.h.h.TableName) 
 --

 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9337-v0.patch


 the user_permission shell code is trying to convert a TableName object to a 
 string, and it throws
 {code}
 hbase(main):010:0 user_permission 
 UserTable,Family,Qualifier:Permission 
   
 
 ERROR: no method 'toStringBinary' for arguments 
 (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
   available overloads:
 (java.nio.ByteBuffer)
 (byte[])
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9340) revoke 'user' throws ArrayIndexOutOfBoundsException

2013-08-26 Thread Matteo Bertozzi (JIRA)

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

Matteo Bertozzi updated HBASE-9340:
---

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

 revoke 'user' throws ArrayIndexOutOfBoundsException
 ---

 Key: HBASE-9340
 URL: https://issues.apache.org/jira/browse/HBASE-9340
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9340-v0.patch


 Trying to revoke a global rights throws
 {code}
 hbase(main):004:0 revoke 'test'
 Java::JavaLang::ArrayIndexOutOfBoundsException: 3
 {code}
 The problem is that jruby is not able to do the bind with revoke(..., 
 Permission.Action... actions)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-7462) TestDrainingServer is an integration test. It should be a unit test instead

2013-08-26 Thread Nicolas Liochon (JIRA)

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

Nicolas Liochon commented on HBASE-7462:


Still in my todo list. Sorry for the delay.

 TestDrainingServer is an integration test. It should be a unit test instead
 ---

 Key: HBASE-7462
 URL: https://issues.apache.org/jira/browse/HBASE-7462
 Project: HBase
  Issue Type: Wish
  Components: test
Affects Versions: 0.95.2
Reporter: Nicolas Liochon
Assignee: Gustavo Anatoly
Priority: Trivial
  Labels: noob
 Attachments: HBASE-7462-v2.patch


 TestDrainingServer tests the function that allows to say that a regionserver 
 should not get new regions.
 As it is written today, it's an integration test: it starts  stops a cluster.
 The test would be more efficient if it would just check that the 
 AssignmentManager does not use the drained region server; whatever the 
 circumstances (bulk assign or not for example).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark reassigned HBASE-9339:


Assignee: Elliott Clark

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 0.98.0, 0.95.2
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-9339-0.patch


 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (HBASE-9341) Document hbase.hstore.compaction.kv.max

2013-08-26 Thread Adrien Mogenet (JIRA)
Adrien Mogenet created HBASE-9341:
-

 Summary: Document hbase.hstore.compaction.kv.max
 Key: HBASE-9341
 URL: https://issues.apache.org/jira/browse/HBASE-9341
 Project: HBase
  Issue Type: Task
  Components: documentation
Reporter: Adrien Mogenet


This setting is used within {{Compactor.java}}, apparently since 0.90 but has 
never been documented. It could be useful for people using very wide rows or 
those who want to fine tune their compactions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9337:
---

FAILURE: Integrated in hbase-0.95-on-hadoop2 #273 (See 
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/273/])
HBASE-9337 shell 'user_permission' throws no method 'toStringBinary' for 
(o.a.h.h.TableName) (mbertozzi: rev 1517666)
* /hbase/branches/0.95/hbase-server/src/main/ruby/hbase/security.rb


 shell 'user_permission' throws no method 'toStringBinary' for 
 (o.a.h.h.TableName) 
 --

 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9337-v0.patch


 the user_permission shell code is trying to convert a TableName object to a 
 string, and it throws
 {code}
 hbase(main):010:0 user_permission 
 UserTable,Family,Qualifier:Permission 
   
 
 ERROR: no method 'toStringBinary' for arguments 
 (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
   available overloads:
 (java.nio.ByteBuffer)
 (byte[])
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9332) OrderedBytes does not decode Strings correctly

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9332:
---

FAILURE: Integrated in hbase-0.95-on-hadoop2 #273 (See 
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/273/])
HBASE-9332 OrderedBytes does not decode Strings correctly (stack: rev 1517656)
* 
/hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/util/OrderedBytes.java
* 
/hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/util/SimplePositionedByteRange.java
* 
/hbase/branches/0.95/hbase-common/src/test/java/org/apache/hadoop/hbase/util/TestOrderedBytes.java


 OrderedBytes does not decode Strings correctly
 --

 Key: HBASE-9332
 URL: https://issues.apache.org/jira/browse/HBASE-9332
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Nick Dimiduk
Assignee: Nick Dimiduk
 Fix For: 0.98.0, 0.96.0

 Attachments: 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch, 
 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch


 While writing a test describing the expected behavior for HBASE-9283, I 
 discovered an error in String decoding. The error occurs when the string 
 being decoded does not start at position 0. The unit tests were originally 
 designed to cover this scenario, but this condition slipped in the transition 
 to PositionedByteBuffer.
 Update the tests to cover this scenario and fix the String decoding logic. 
 String appears to be the only codec affected. This error is only in decoding 
 -- encoding produces correct byte[].

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9312) Lower StochasticLoadBalancer's default max run time

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9312:
---

FAILURE: Integrated in hbase-0.95-on-hadoop2 #273 (See 
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/273/])
HBASE-9312 Lower StochasticLoadBalancer's default max run time (eclark: rev 
1517648)
* 
/hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java


 Lower StochasticLoadBalancer's default max run time 
 

 Key: HBASE-9312
 URL: https://issues.apache.org/jira/browse/HBASE-9312
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Jean-Daniel Cryans
Assignee: Elliott Clark
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9312-0.patch


 Three things about the 1 minute it takes to decide if we want to balance or 
 not:
  - 1 minute is also the default socket timeout, so if you call balancer in 
 the shell you often get a SocketTimeoutException back. Bad user experience.
  - Elliott was telling me that we might not even need 1 minute to compute a 
 good balance anyways because of other improvements. I tested 30 seconds on a 
 badly balanced cluster and it worked well.
  - I personally think that 1 minute is too much time (Elliott disagrees).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9329) SnapshotManager should check for directory existance before throwing a warning.

2013-08-26 Thread Hudson (JIRA)

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

Hudson commented on HBASE-9329:
---

FAILURE: Integrated in hbase-0.95-on-hadoop2 #273 (See 
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/273/])
HBASE-9329 SnapshotManager should check for directory existance before throwing 
a warning (Jean-Marc Spaggiari) (mbertozzi: rev 1517610)
* 
/hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/SnapshotManager.java


 SnapshotManager should check for directory existance before throwing a 
 warning.
 ---

 Key: HBASE-9329
 URL: https://issues.apache.org/jira/browse/HBASE-9329
 Project: HBase
  Issue Type: Bug
  Components: snapshots
Affects Versions: 0.98.0, 0.95.2, 0.94.11
Reporter: Jean-Marc Spaggiari
Assignee: Jean-Marc Spaggiari
Priority: Trivial
 Fix For: 0.98.0, 0.95.2, 0.94.12

 Attachments: HBASE-9329-v0-trunk.patch


 {quote}
 2013-08-23 17:57:24,277 WARN 
 org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete 
 working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
 {quote}
 I don't have any .hbase-snapshot directory, so there is no need to try to 
 delete the .tmp directory into it. Might first need to check if this 
 directory exist.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Resolved] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark resolved HBASE-9339.
--

  Resolution: Fixed
Hadoop Flags: Reviewed

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 0.98.0, 0.95.2
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-9339-0.patch


 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (HBASE-9341) Document hbase.hstore.compaction.kv.max

2013-08-26 Thread stack (JIRA)

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

stack updated HBASE-9341:
-

 Priority: Critical  (was: Major)
Fix Version/s: 0.96.0
   0.98.0
 Assignee: stack

 Document hbase.hstore.compaction.kv.max
 ---

 Key: HBASE-9341
 URL: https://issues.apache.org/jira/browse/HBASE-9341
 Project: HBase
  Issue Type: Task
  Components: documentation
Reporter: Adrien Mogenet
Assignee: stack
Priority: Critical
  Labels: compaction
 Fix For: 0.98.0, 0.96.0


 This setting is used within {{Compactor.java}}, apparently since 0.90 but has 
 never been documented. It could be useful for people using very wide rows or 
 those who want to fine tune their compactions.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-8960) TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes

2013-08-26 Thread Jeffrey Zhong (JIRA)

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

Jeffrey Zhong commented on HBASE-8960:
--

[~saint@gmail.com] Should I close this JIRA now because 
TestDistributedLogSplitting hasn't failed in last 10+ builds on trunk, 0.95 and 
0.95 on hadoop2? Thanks.

 TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
 --

 Key: HBASE-8960
 URL: https://issues.apache.org/jira/browse/HBASE-8960
 Project: HBase
  Issue Type: Task
  Components: test
Reporter: Jimmy Xiang
Assignee: Jeffrey Zhong
Priority: Minor
 Fix For: 0.96.0

 Attachments: hbase-8690-v4.patch, hbase-8960-addendum-2.patch, 
 hbase-8960-addendum.patch, 
 hbase-8960-fix-disallowWritesInRecovering-addendum.patch, 
 hbase-8960-fix-disallowWritesInRecovering.patch, hbase-8960.patch


 http://54.241.6.143/job/HBase-0.95-Hadoop-2/org.apache.hbase$hbase-server/634/testReport/junit/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testLogReplayForDisablingTable/
 {noformat}
 java.lang.AssertionError: expected:1000 but was:0
   at org.junit.Assert.fail(Assert.java:88)
   at org.junit.Assert.failNotEquals(Assert.java:743)
   at org.junit.Assert.assertEquals(Assert.java:118)
   at org.junit.Assert.assertEquals(Assert.java:555)
   at org.junit.Assert.assertEquals(Assert.java:542)
   at 
 org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testLogReplayForDisablingTable(TestDistributedLogSplitting.java:797)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9299) Generate the protobuf classes with hadoop-maven-plugin

2013-08-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-9299:
--

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

{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 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{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:red}-1 release audit{color}.  The applied patch generated 2 release 
audit warnings (more than the trunk's current 0 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/6903//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6903//console

This message is automatically generated.

 Generate the protobuf classes with hadoop-maven-plugin
 --

 Key: HBASE-9299
 URL: https://issues.apache.org/jira/browse/HBASE-9299
 Project: HBase
  Issue Type: New Feature
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9299.patch


 For now, the protobuf classes are generated once by a dev, and put in 
 src/main/resouce. 
 This allows the other dev to not have the correct protoc version available on 
 their machine. However, when a dev wants to modify the protoc messages, he 
 has to know how to generate the classes. This could be documented...
 Another approach would be to put a harder requirement on the hbase developers 
 (protoc available) and let the hadoop-maven-plugin 
 (http://central.maven.org/maven2/org/apache/hadoop/hadoop-maven-plugins/2.0.5-alpha)
  to do the work (I have bad experience with other maven protobuf plugins, the 
 hadoop one works just out of the box).
 I don't think asking to install protoc to build hbase is so difficult, but 
 that's an additional step between the dev and the artifcat.
 The advantage would be to allow to have different protobuf versions for 
 different hbase distributions (perfectly possible but quite theorical).
 So
 option 1: We are happy to keep the classes in src/main/java
 option 2: We want to move to hadoop-maven-plugin 
 option 3: I may be short of idea... any other input?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-7709) Infinite loop possible in Master/Master replication

2013-08-26 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on HBASE-7709:
--

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/1250/0.95-trunk-rev4.patch
  against trunk revision .

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

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

{color:green}+1 hadoop1.0{color}.  The patch compiles against the hadoop 
1.0 profile.

{color:green}+1 hadoop2.0{color}.  The patch compiles against the hadoop 
2.0 profile.

{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:red}-1 release audit{color}.  The applied patch generated 2 release 
audit warnings (more than the trunk's current 0 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/6902//testReport/
Release audit warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6902//console

This message is automatically generated.

 Infinite loop possible in Master/Master replication
 ---

 Key: HBASE-7709
 URL: https://issues.apache.org/jira/browse/HBASE-7709
 Project: HBase
  Issue Type: Bug
  Components: Replication
Affects Versions: 0.94.6, 0.95.1
Reporter: Lars Hofhansl
Assignee: Vasu Mariyala
 Fix For: 0.98.0, 0.94.12, 0.96.0

 Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, 
 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, 
 HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, 
 HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch


  We just discovered the following scenario:
 # Cluster A and B are setup in master/master replication
 # By accident we had Cluster C replicate to Cluster A.
 Now all edit originating from C will be bouncing between A and B. Forever!
 The reason is that when the edit come in from C the cluster ID is already set 
 and won't be reset.
 We have a couple of options here:
 # Optionally only support master/master (not cycles of more than two 
 clusters). In that case we can always reset the cluster ID in the 
 ReplicationSource. That means that now cycles  2 will have the data cycle 
 forever. This is the only option that requires no changes in the HLog format.
 # Instead of a single cluster id per edit maintain a (unordered) set of 
 cluster id that have seen this edit. Then in ReplicationSource we drop any 
 edit that the sink has seen already. The is the cleanest approach, but it 
 might need a lot of data stored per edit if there are many clusters involved.
 # Maintain a configurable counter of the maximum cycle side we want to 
 support. Could default to 10 (even maybe even just). Store a hop-count in the 
 WAL and the ReplicationSource increases that 

[jira] [Commented] (HBASE-9337) shell 'user_permission' throws no method 'toStringBinary' for (o.a.h.h.TableName)

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk commented on HBASE-9337:
-

[~yuzhih...@gmail.com] posted an addendum patch for this issue over on 
HBASE-9281. Have a look at my 
[comment|https://issues.apache.org/jira/browse/HBASE-9281?focusedCommentId=13750344page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13750344];
 I think {{getNameAsString}} should be used instead of {{toString}}.

 shell 'user_permission' throws no method 'toStringBinary' for 
 (o.a.h.h.TableName) 
 --

 Key: HBASE-9337
 URL: https://issues.apache.org/jira/browse/HBASE-9337
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9337-v0.patch


 the user_permission shell code is trying to convert a TableName object to a 
 string, and it throws
 {code}
 hbase(main):010:0 user_permission 
 UserTable,Family,Qualifier:Permission 
   
 
 ERROR: no method 'toStringBinary' for arguments 
 (org.apache.hadoop.hbase.TableName) on Java::OrgApacheHadoopHbaseUtil::Bytes
   available overloads:
 (java.nio.ByteBuffer)
 (byte[])
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk commented on HBASE-9339:
-

This is a step toward converting the repository of record over to git, right..? 
;)

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 0.98.0, 0.95.2
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-9339-0.patch


 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9340) revoke 'user' throws ArrayIndexOutOfBoundsException

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk commented on HBASE-9340:
-

nit: no need for that extra newline.

 revoke 'user' throws ArrayIndexOutOfBoundsException
 ---

 Key: HBASE-9340
 URL: https://issues.apache.org/jira/browse/HBASE-9340
 Project: HBase
  Issue Type: Bug
  Components: security, shell
Affects Versions: 0.95.2
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
 Fix For: 0.98.0, 0.96.0

 Attachments: HBASE-9340-v0.patch


 Trying to revoke a global rights throws
 {code}
 hbase(main):004:0 revoke 'test'
 Java::JavaLang::ArrayIndexOutOfBoundsException: 3
 {code}
 The problem is that jruby is not able to do the bind with revoke(..., 
 Permission.Action... actions)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9339) Fix saveVersion.sh's GIT awareness.

2013-08-26 Thread Elliott Clark (JIRA)

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

Elliott Clark commented on HBASE-9339:
--

haha I wish.  I've been doing git svn dcommit for a while now; better than no 
git at all.

 Fix saveVersion.sh's GIT awareness.
 ---

 Key: HBASE-9339
 URL: https://issues.apache.org/jira/browse/HBASE-9339
 Project: HBase
  Issue Type: Task
  Components: build
Affects Versions: 0.98.0, 0.95.2
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-9339-0.patch


 Many developers are using git to work with HBase.  We should make the build 
 scripts git aware (point to a git hash ) for revision.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (HBASE-9281) user_permission command encounters NullPointerException

2013-08-26 Thread Nick Dimiduk (JIRA)

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

Nick Dimiduk commented on HBASE-9281:
-

Looks like the need for this addendum is made moot by HBASE-9337.

 user_permission command encounters NullPointerException
 ---

 Key: HBASE-9281
 URL: https://issues.apache.org/jira/browse/HBASE-9281
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Ted Yu
Assignee: Ted Yu
 Attachments: 9281.addendum, 9281-v1.txt


 As user hbase, user_permission command gave:
 {code}
 java.io.IOException: java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2147)
   ... 1 more
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at 
 org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
   at 
 org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:235)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.execService(ProtobufUtil.java:1304)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:87)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:84)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:120)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:98)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel.callExecService(RegionCoprocessorRpcChannel.java:90)
   at 
 org.apache.hadoop.hbase.ipc.CoprocessorRpcChannel.callBlockingMethod(CoprocessorRpcChannel.java:67)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$BlockingStub.getUserPermissions(AccessControlProtos.java:10304)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getUserPermissions(ProtobufUtil.java:1974)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
 ...
 Caused by: 
 org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException): 
 java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
   at 

[jira] [Commented] (HBASE-9281) user_permission command encounters NullPointerException

2013-08-26 Thread Ted Yu (JIRA)

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

Ted Yu commented on HBASE-9281:
---

Plan to resolve this JIRA tomorrow.

 user_permission command encounters NullPointerException
 ---

 Key: HBASE-9281
 URL: https://issues.apache.org/jira/browse/HBASE-9281
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.95.2
Reporter: Ted Yu
Assignee: Ted Yu
 Attachments: 9281.addendum, 9281-v1.txt


 As user hbase, user_permission command gave:
 {code}
 java.io.IOException: java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2147)
   ... 1 more
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at 
 org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
   at 
 org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:235)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.execService(ProtobufUtil.java:1304)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:87)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:84)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:120)
   at 
 org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:98)
   at 
 org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel.callExecService(RegionCoprocessorRpcChannel.java:90)
   at 
 org.apache.hadoop.hbase.ipc.CoprocessorRpcChannel.callBlockingMethod(CoprocessorRpcChannel.java:67)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$BlockingStub.getUserPermissions(AccessControlProtos.java:10304)
   at 
 org.apache.hadoop.hbase.protobuf.ProtobufUtil.getUserPermissions(ProtobufUtil.java:1974)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
 ...
 Caused by: 
 org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException): 
 java.io.IOException
   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
   at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
 Caused by: java.lang.NullPointerException
   at 
 org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
   at 
 org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
   at 
 org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
   at 
 org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
   at 
 org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
   at 
 org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
   at 

  1   2   3   >