[jira] [Updated] (HBASE-9306) [0.92] TestAdmin.testCreateBadTables fails occasionally
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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)
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)
[ 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)
[ 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
[ 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
[ 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)
[ 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)
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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
[ 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.
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
[ 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
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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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
[ 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.
[ 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.
[ 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
[ 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.
[ 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.
[ 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.
[ 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.
[ 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.
[ 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
[ 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)
[ 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
[ 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
[ 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.
[ 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
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)
[ 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
[ 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
[ 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.
[ 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.
[ 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
[ 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
[ 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
[ 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
[ 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)
[ 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.
[ 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
[ 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.
[ 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
[ 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
[ 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