[jira] [Updated] (HBASE-4811) Support reverse Scan
[ https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunhui shen updated HBASE-4811: Attachment: hbase-4811-trunkv16.patch > Support reverse Scan > > > Key: HBASE-4811 > URL: https://issues.apache.org/jira/browse/HBASE-4811 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 0.20.6, 0.94.7 >Reporter: John Carrino >Assignee: Liang Xie > Fix For: 0.98.0 > > Attachments: 4811-trunk-v10.txt, 4811-trunk-v5.patch, > HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt, > hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch, > hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch, > hbase-4811-trunkv15.patch, hbase-4811-trunkv16.patch, > hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch, > hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch > > > All the documentation I find about HBase says that if you want forward and > reverse scans you should just build 2 tables and one be ascending and one > descending. Is there a fundamental reason that HBase only supports forward > Scan? It seems like a lot of extra space overhead and coding overhead (to > keep them in sync) to support 2 tables. > I am assuming this has been discussed before, but I can't find the > discussions anywhere about it or why it would be infeasible. -- 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-4811) Support reverse Scan
[ https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunhui shen updated HBASE-4811: Attachment: hbase-4811-trunkv15.patch Upload the newest patch based on trunk > Support reverse Scan > > > Key: HBASE-4811 > URL: https://issues.apache.org/jira/browse/HBASE-4811 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 0.20.6, 0.94.7 >Reporter: John Carrino >Assignee: Liang Xie > Fix For: 0.98.0 > > Attachments: 4811-trunk-v10.txt, 4811-trunk-v5.patch, > HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt, > hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch, > hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch, > hbase-4811-trunkv15.patch, hbase-4811-trunkv1.patch, > hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch, hbase-4811-trunkv7.patch, > hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch > > > All the documentation I find about HBase says that if you want forward and > reverse scans you should just build 2 tables and one be ascending and one > descending. Is there a fundamental reason that HBase only supports forward > Scan? It seems like a lot of extra space overhead and coding overhead (to > keep them in sync) to support 2 tables. > I am assuming this has been discussed before, but I can't find the > discussions anywhere about it or why it would be infeasible. -- 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-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741955#comment-13741955
]
Hudson commented on HBASE-9023:
---
SUCCESS: Integrated in hbase-0.95 #457 (See
[https://builds.apache.org/job/hbase-0.95/457/])
HBASE-9023 TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally
fails (tedyu: rev 1514550)
*
/hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> 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-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] [Commented] (HBASE-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741956#comment-13741956
]
Hudson commented on HBASE-9236:
---
SUCCESS: Integrated in hbase-0.95 #457 (See
[https://builds.apache.org/job/hbase-0.95/457/])
HBASE-9236 region_mover#getTable() should use TableName.toString() instead of
Bytes.toString() (tedyu: rev 1514553)
* /hbase/branches/0.95/bin/region_mover.rb
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9246) Remove ROOT_TABLEDESC, ROOT_REGIONINFO, and ROOT_TABLE_NAME
[ https://issues.apache.org/jira/browse/HBASE-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-9246: -- Attachment: hbase-9246.patch > Remove ROOT_TABLEDESC, ROOT_REGIONINFO, and ROOT_TABLE_NAME > --- > > Key: HBASE-9246 > URL: https://issues.apache.org/jira/browse/HBASE-9246 > Project: HBase > Issue Type: Sub-task >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-9246.patch > > > ROOT has been removed from trunk / 0.95 but is still present in namespaces > code and in unit tests. This culls these references. -- 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-9246) Remove ROOT_TABLEDESC, ROOT_REGIONINFO, and ROOT_TABLE_NAME
[ https://issues.apache.org/jira/browse/HBASE-9246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-9246: -- Status: Patch Available (was: Open) > Remove ROOT_TABLEDESC, ROOT_REGIONINFO, and ROOT_TABLE_NAME > --- > > Key: HBASE-9246 > URL: https://issues.apache.org/jira/browse/HBASE-9246 > Project: HBase > Issue Type: Sub-task >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-9246.patch > > > ROOT has been removed from trunk / 0.95 but is still present in namespaces > code and in unit tests. This culls these references. -- 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: HBASE-7709-095.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 > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: HBASE-7709.patch, HBASE-7709-rev1.patch, > HBASE-7709-rev2.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-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: HBASE-7709-095-trunk.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 > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: HBASE-7709-095-trunk.patch, HBASE-7709.patch, > HBASE-7709-rev1.patch, HBASE-7709-rev2.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-7709) Infinite loop possible in Master/Master replication
[
https://issues.apache.org/jira/browse/HBASE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741951#comment-13741951
]
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/12598360/HBASE-7709-095.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:red}-1 javadoc{color}. The javadoc tool appears to have generated 1
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.wal.TestHLog
org.apache.hadoop.hbase.migration.TestNamespaceUpgrade
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6777//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
> Fix For: 0.98.0, 0.94.12, 0.96.0
>
> Attachments: HBASE-7709-095.patch, HBASE-7709.patch,
> HBASE-7709-rev1.patch, HBASE-7709-rev2.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 contac
[jira] [Created] (HBASE-9247) Cleanup Key/KV/Meta/MetaKey Comparators
Jonathan Hsieh created HBASE-9247: - Summary: Cleanup Key/KV/Meta/MetaKey Comparators Key: HBASE-9247 URL: https://issues.apache.org/jira/browse/HBASE-9247 Project: HBase Issue Type: Sub-task Reporter: Jonathan Hsieh Assignee: Jonathan Hsieh HBASE-9164 converted KVComparator's KeyCompare#compare guts from one that assumed a contiguous array backing a KV to one that used the Cell interface which doesn't have this assumption. There is now duplicate code that should be cleaned up. -- 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-9246) Remove ROOT_TABLEDESC, ROOT_REGIONINFO, and ROOT_TABLE_NAME
Jonathan Hsieh created HBASE-9246: - Summary: Remove ROOT_TABLEDESC, ROOT_REGIONINFO, and ROOT_TABLE_NAME Key: HBASE-9246 URL: https://issues.apache.org/jira/browse/HBASE-9246 Project: HBase Issue Type: Sub-task Reporter: Jonathan Hsieh Assignee: Jonathan Hsieh ROOT has been removed from trunk / 0.95 but is still present in namespaces code and in unit tests. This culls these references. -- 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-9245) Remove dead code from hbase 0.96
[ https://issues.apache.org/jira/browse/HBASE-9245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Hsieh updated HBASE-9245: -- Description: This is an umbrella issue that will cover the removal or refactoring of dangling dead code and cruft. Some can make it into 0.96, some may have to wait for an 0.98. The "great culling" of code will be grouped patches that are logically related. (was: This is an umbrella issue that will cover the removal or refactoring of dangling dead code and cruft. Some can make it into 0.96, some may have to wait for an 0.98.) > Remove dead code from hbase 0.96 > > > Key: HBASE-9245 > URL: https://issues.apache.org/jira/browse/HBASE-9245 > Project: HBase > Issue Type: Bug >Reporter: Jonathan Hsieh > > This is an umbrella issue that will cover the removal or refactoring of > dangling dead code and cruft. Some can make it into 0.96, some may have to > wait for an 0.98. The "great culling" of code will be grouped patches that > are logically related. -- 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-9245) Remove dead code from hbase 0.96
Jonathan Hsieh created HBASE-9245: - Summary: Remove dead code from hbase 0.96 Key: HBASE-9245 URL: https://issues.apache.org/jira/browse/HBASE-9245 Project: HBase Issue Type: Bug Reporter: Jonathan Hsieh This is an umbrella issue that will cover the removal or refactoring of dangling dead code and cruft. Some can make it into 0.96, some may have to wait for an 0.98. -- 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-8348) Polish the migration to 0.96
[ https://issues.apache.org/jira/browse/HBASE-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741932#comment-13741932 ] Himanshu Vashishtha commented on HBASE-8348: I agree that backup tool is more involved and is over weight for this purpose. It could be used where we want to take snapshot of znodes, etc. To upgrade to PB, let's use the in place approach. > Polish the migration to 0.96 > > > Key: HBASE-8348 > URL: https://issues.apache.org/jira/browse/HBASE-8348 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.0 >Reporter: Jean-Daniel Cryans >Assignee: rajeshbabu >Priority: Critical > Fix For: 0.96.0 > > Attachments: HBASE-8348_trunk.patch, HBASE-8348_trunk_v2.patch, > HBASE-8348_trunk_v3.patch > > > Currently, migration works but there's still a couple of rough edges: > - HBASE-8045 finished the .META. migration but didn't remove ROOT, so it's > still on the filesystem. > - Data in ZK needs to be removed manually. Either we fix up the data in ZK > or we delete it ourselves. > - TestMetaMigrationRemovingHTD has a testMetaUpdatedFlagInROOT method, but > ROOT is gone now. > Elliott was also mentioning that we could have "hbase migrate" do the HFileV1 > checks, clear ZK, remove ROOT, etc. -- 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-8754) Log the client IP/port of the balancer invoker
[ https://issues.apache.org/jira/browse/HBASE-8754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741923#comment-13741923 ] Harsh J commented on HBASE-8754: I'm not sure of how HBase manages audit log events but in HDFS we use the UGI object associated with the call: https://github.com/apache/hadoop-common/blob/release-2.0.5-alpha/hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/FSNamesystem.java#L5270 > Log the client IP/port of the balancer invoker > -- > > Key: HBASE-8754 > URL: https://issues.apache.org/jira/browse/HBASE-8754 > Project: HBase > Issue Type: Improvement > Components: master, Usability >Affects Versions: 0.90.0 >Reporter: Harsh J > Fix For: 0.96.0 > > > There's no way for any ops to answer today: "Who turned off/on the > balancer?". All the logs print is the state when the RPC call is invoked, > nothing else. > Given this is a critical piece of admin functionality, we should log the IP > for it at least. -- 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-9243) Add more useful statistics in the HFile tool
[
https://issues.apache.org/jira/browse/HBASE-9243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Normand updated HBASE-9243:
-
Status: Patch Available (was: Open)
The description of the JIRA had all the juicy details of what I was including
in the patch so there's nothing more to say here except that the patch is there
and available for review.
> Add more useful statistics in the HFile tool
>
>
> Key: HBASE-9243
> URL: https://issues.apache.org/jira/browse/HBASE-9243
> Project: HBase
> Issue Type: Improvement
> Components: HFile
>Affects Versions: 0.96.0
>Reporter: Alexandre Normand
>Priority: Minor
> Labels: newbie
> Attachments: HBASE-9243.patch
>
>
> The [HFile tool|http://hbase.apache.org/book/regions.arch.html#hfile_tool]
> has been very useful to us recently to get a better idea of the size of our
> rows. However, it happened frequently that we wished for more statistics to
> have a more complete picture of the distribution of the row sizes.
> [~skuehn] requested that feature often enough in private that I decided to
> give it a go.
> Here's the patch that adds more nice little stats via yammer's histograms. It
> was easy enough since {{com.yammer.metrics}} is already in hbase's
> dependencies.
> Example of the new output from {{org.apache.hadoop.hbase.io.hfile.HFile -s -f
> ...}}:
> {code}
> Stats:
> Key length:
>min = 24.00
>max = 24.00
> mean = 24.00
> stddev = 0.00
> median = 24.00
> 75% <= 24.00
> 95% <= 24.00
> 98% <= 24.00
> 99% <= 24.00
> 99.9% <= 24.00
> Row size (bytes):
>min = 33.00
>max = 33.00
> mean = 33.00
> stddev = 0.00
> median = 33.00
> 75% <= 33.00
> 95% <= 33.00
> 98% <= 33.00
> 99% <= 33.00
> 99.9% <= 33.00
> Row size (columns):
>min = 1.00
>max = 1.00
> mean = 1.00
> stddev = 0.00
> median = 1.00
> 75% <= 1.00
> 95% <= 1.00
> 98% <= 1.00
> 99% <= 1.00
> 99.9% <= 1.00
> Val length:
>min = 1.00
>max = 1.00
> mean = 1.00
> stddev = 0.00
> median = 1.00
> 75% <= 1.00
> 95% <= 1.00
> 98% <= 1.00
> 99% <= 1.00
> 99.9% <= 1.00
> Key of biggest row: \x00
> {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-9243) Add more useful statistics in the HFile tool
[
https://issues.apache.org/jira/browse/HBASE-9243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexandre Normand updated HBASE-9243:
-
Attachment: HBASE-9243.patch
> Add more useful statistics in the HFile tool
>
>
> Key: HBASE-9243
> URL: https://issues.apache.org/jira/browse/HBASE-9243
> Project: HBase
> Issue Type: Improvement
> Components: HFile
>Affects Versions: 0.96.0
>Reporter: Alexandre Normand
>Priority: Minor
> Labels: newbie
> Attachments: HBASE-9243.patch
>
>
> The [HFile tool|http://hbase.apache.org/book/regions.arch.html#hfile_tool]
> has been very useful to us recently to get a better idea of the size of our
> rows. However, it happened frequently that we wished for more statistics to
> have a more complete picture of the distribution of the row sizes.
> [~skuehn] requested that feature often enough in private that I decided to
> give it a go.
> Here's the patch that adds more nice little stats via yammer's histograms. It
> was easy enough since {{com.yammer.metrics}} is already in hbase's
> dependencies.
> Example of the new output from {{org.apache.hadoop.hbase.io.hfile.HFile -s -f
> ...}}:
> {code}
> Stats:
> Key length:
>min = 24.00
>max = 24.00
> mean = 24.00
> stddev = 0.00
> median = 24.00
> 75% <= 24.00
> 95% <= 24.00
> 98% <= 24.00
> 99% <= 24.00
> 99.9% <= 24.00
> Row size (bytes):
>min = 33.00
>max = 33.00
> mean = 33.00
> stddev = 0.00
> median = 33.00
> 75% <= 33.00
> 95% <= 33.00
> 98% <= 33.00
> 99% <= 33.00
> 99.9% <= 33.00
> Row size (columns):
>min = 1.00
>max = 1.00
> mean = 1.00
> stddev = 0.00
> median = 1.00
> 75% <= 1.00
> 95% <= 1.00
> 98% <= 1.00
> 99% <= 1.00
> 99.9% <= 1.00
> Val length:
>min = 1.00
>max = 1.00
> mean = 1.00
> stddev = 0.00
> median = 1.00
> 75% <= 1.00
> 95% <= 1.00
> 98% <= 1.00
> 99% <= 1.00
> 99.9% <= 1.00
> Key of biggest row: \x00
> {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-9244) Add CP hooks around HalfStoreFileReader creation
Anoop Sam John created HBASE-9244: - Summary: Add CP hooks around HalfStoreFileReader creation Key: HBASE-9244 URL: https://issues.apache.org/jira/browse/HBASE-9244 Project: HBase Issue Type: Sub-task Reporter: Anoop Sam John -- 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-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741917#comment-13741917
]
Hudson commented on HBASE-9236:
---
FAILURE: Integrated in HBase-TRUNK #4400 (See
[https://builds.apache.org/job/HBase-TRUNK/4400/])
HBASE-9236 region_mover#getTable() should use TableName.toString() instead of
Bytes.toString() (tedyu: rev 1514552)
* /hbase/trunk/bin/region_mover.rb
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9203) Secondary index support through coprocessors
[ https://issues.apache.org/jira/browse/HBASE-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741915#comment-13741915 ] Anoop Sam John commented on HBASE-9203: --- bq.If the number of index tables increases, what would the put performance be like ? Just to make it clear, There will be only one index table per actual table, irrespective of the #indices. Yes need to calculate the put performance throughput with say 2,3,5 indices also (?) > Secondary index support through coprocessors > > > Key: HBASE-9203 > URL: https://issues.apache.org/jira/browse/HBASE-9203 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.98.0 >Reporter: rajeshbabu >Assignee: rajeshbabu > > We have been working on implementing secondary index in HBase and open > sourced on hbase 0.94.8 version. > The project is available on github. > https://github.com/Huawei-Hadoop/hindex > This Jira is to support secondary index on trunk(0.98). > Following features will be supported. > - multiple indexes on table, > - multi column index, > - index based on part of a column value, > - equals and range condition scans using index, and > - bulk loading data to indexed table (Indexing done with bulk load) > Most of the kernel changes needed for secondary index is available in trunk. > Very minimal changes needed for it. -- 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-9243) Add more useful statistics in the HFile tool
Alexandre Normand created HBASE-9243:
Summary: Add more useful statistics in the HFile tool
Key: HBASE-9243
URL: https://issues.apache.org/jira/browse/HBASE-9243
Project: HBase
Issue Type: Improvement
Components: HFile
Affects Versions: 0.96.0
Reporter: Alexandre Normand
Priority: Minor
The [HFile tool|http://hbase.apache.org/book/regions.arch.html#hfile_tool] has
been very useful to us recently to get a better idea of the size of our rows.
However, it happened frequently that we wished for more statistics to have a
more complete picture of the distribution of the row sizes.
[~skuehn] requested that feature often enough in private that I decided to give
it a go.
Here's the patch that adds more nice little stats via yammer's histograms. It
was easy enough since {{com.yammer.metrics}} is already in hbase's dependencies.
Example of the new output from {{org.apache.hadoop.hbase.io.hfile.HFile -s -f
...}}:
{code}
Stats:
Key length:
min = 24.00
max = 24.00
mean = 24.00
stddev = 0.00
median = 24.00
75% <= 24.00
95% <= 24.00
98% <= 24.00
99% <= 24.00
99.9% <= 24.00
Row size (bytes):
min = 33.00
max = 33.00
mean = 33.00
stddev = 0.00
median = 33.00
75% <= 33.00
95% <= 33.00
98% <= 33.00
99% <= 33.00
99.9% <= 33.00
Row size (columns):
min = 1.00
max = 1.00
mean = 1.00
stddev = 0.00
median = 1.00
75% <= 1.00
95% <= 1.00
98% <= 1.00
99% <= 1.00
99.9% <= 1.00
Val length:
min = 1.00
max = 1.00
mean = 1.00
stddev = 0.00
median = 1.00
75% <= 1.00
95% <= 1.00
98% <= 1.00
99% <= 1.00
99.9% <= 1.00
Key of biggest row: \x00
{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-tabpanel&focusedCommentId=13741909#comment-13741909 ] Vasu Mariyala commented on HBASE-7709: -- 0.95 patch works for trunk as well. > 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 > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: HBASE-7709-095.patch, HBASE-7709.patch, > HBASE-7709-rev1.patch, HBASE-7709-rev2.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-8348) Polish the migration to 0.96
[ https://issues.apache.org/jira/browse/HBASE-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741911#comment-13741911 ] rajeshbabu commented on HBASE-8348: --- Himanshu, bq. a) I think you should also remove the hbase.id znode as master has to rewrite it anyway. Also, talking to Matteo, also delete online-snapshot znode. That way, there will be only two znodes left: table, replication. I will remove these. If we use replication znode backup tool, failures can happen in multiple places a) while taking backup b) deleting znodes c) while restoring right? Need to handle all cases and user also need to aware of them while running again on failure? But with replacement, just if we run the same command again we can continue from the place where its failed. Its simple to use also. Lets see what others will say about this. If its ok to use backup tool, for me also no problem. > Polish the migration to 0.96 > > > Key: HBASE-8348 > URL: https://issues.apache.org/jira/browse/HBASE-8348 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.0 >Reporter: Jean-Daniel Cryans >Assignee: rajeshbabu >Priority: Critical > Fix For: 0.96.0 > > Attachments: HBASE-8348_trunk.patch, HBASE-8348_trunk_v2.patch, > HBASE-8348_trunk_v3.patch > > > Currently, migration works but there's still a couple of rough edges: > - HBASE-8045 finished the .META. migration but didn't remove ROOT, so it's > still on the filesystem. > - Data in ZK needs to be removed manually. Either we fix up the data in ZK > or we delete it ourselves. > - TestMetaMigrationRemovingHTD has a testMetaUpdatedFlagInROOT method, but > ROOT is gone now. > Elliott was also mentioning that we could have "hbase migrate" do the HFileV1 > checks, clear ZK, remove ROOT, etc. -- 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-9203) Secondary index support through coprocessors
[ https://issues.apache.org/jira/browse/HBASE-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741904#comment-13741904 ] rajeshbabu commented on HBASE-9203: --- bq. The trunk patch would put new classes for secondaryindex in a new module, I assume. Yes Ted. > Secondary index support through coprocessors > > > Key: HBASE-9203 > URL: https://issues.apache.org/jira/browse/HBASE-9203 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.98.0 >Reporter: rajeshbabu >Assignee: rajeshbabu > > We have been working on implementing secondary index in HBase and open > sourced on hbase 0.94.8 version. > The project is available on github. > https://github.com/Huawei-Hadoop/hindex > This Jira is to support secondary index on trunk(0.98). > Following features will be supported. > - multiple indexes on table, > - multi column index, > - index based on part of a column value, > - equals and range condition scans using index, and > - bulk loading data to indexed table (Indexing done with bulk load) > Most of the kernel changes needed for secondary index is available in trunk. > Very minimal changes needed for it. -- 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-9242) Upgrade slf4j to version 1.7
Ted Yu created HBASE-9242: - Summary: Upgrade slf4j to version 1.7 Key: HBASE-9242 URL: https://issues.apache.org/jira/browse/HBASE-9242 Project: HBase Issue Type: Task Reporter: Ted Yu Priority: Minor Currently we use 1.6.4 for 0.95 We should upgrade to version 1.7 See also HADOOP-9833 -- 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: HBASE-7709-095.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 > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: HBASE-7709-095.patch, HBASE-7709.patch, > HBASE-7709-rev1.patch, HBASE-7709-rev2.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-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: HBASE-7709-095.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 > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: HBASE-7709.patch, HBASE-7709-rev1.patch, > HBASE-7709-rev2.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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741894#comment-13741894
]
Anoop Sam John commented on HBASE-9239:
---
Just seeing the patch I also got the same doubt as Ram mentioned.
bq.The contract of this interface is to return the List in sorted order by
Table name, then ColumnFamily.
Said above , +1 then
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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: HBASE-7709-095.patch Attaching the patch for 0.95 release > 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 > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: HBASE-7709-095.patch, HBASE-7709.patch, > HBASE-7709-rev1.patch, HBASE-7709-rev2.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-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-9023:
--
Component/s: (was: test)
> 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-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] [Updated] (HBASE-4811) Support reverse Scan
[ https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-4811: -- Fix Version/s: 0.98.0 > Support reverse Scan > > > Key: HBASE-4811 > URL: https://issues.apache.org/jira/browse/HBASE-4811 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 0.20.6, 0.94.7 >Reporter: John Carrino >Assignee: Liang Xie > Fix For: 0.98.0 > > Attachments: 4811-trunk-v10.txt, 4811-trunk-v5.patch, > HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt, > hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch, > hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch, > hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch, > hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch > > > All the documentation I find about HBase says that if you want forward and > reverse scans you should just build 2 tables and one be ascending and one > descending. Is there a fundamental reason that HBase only supports forward > Scan? It seems like a lot of extra space overhead and coding overhead (to > keep them in sync) to support 2 tables. > I am assuming this has been discussed before, but I can't find the > discussions anywhere about it or why it would be infeasible. -- 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-4811) Support reverse Scan
[ https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741889#comment-13741889 ] Lars Hofhansl commented on HBASE-4811: -- I think we dropped the ball on this. We should finish this. How do other folks feel about this. The feature is great! We just have to be careful to avoid adding unnecessary APIs to the core scanner classes. > Support reverse Scan > > > Key: HBASE-4811 > URL: https://issues.apache.org/jira/browse/HBASE-4811 > Project: HBase > Issue Type: Improvement > Components: Client >Affects Versions: 0.20.6, 0.94.7 >Reporter: John Carrino >Assignee: Liang Xie > Attachments: 4811-trunk-v10.txt, 4811-trunk-v5.patch, > HBase-4811-0.94.3modified.txt, HBase-4811-0.94-v2.txt, > hbase-4811-trunkv11.patch, hbase-4811-trunkv12.patch, > hbase-4811-trunkv13.patch, hbase-4811-trunkv14.patch, > hbase-4811-trunkv1.patch, hbase-4811-trunkv4.patch, hbase-4811-trunkv6.patch, > hbase-4811-trunkv7.patch, hbase-4811-trunkv8.patch, hbase-4811-trunkv9.patch > > > All the documentation I find about HBase says that if you want forward and > reverse scans you should just build 2 tables and one be ascending and one > descending. Is there a fundamental reason that HBase only supports forward > Scan? It seems like a lot of extra space overhead and coding overhead (to > keep them in sync) to support 2 tables. > I am assuming this has been discussed before, but I can't find the > discussions anywhere about it or why it would be infeasible. -- 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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741883#comment-13741883
]
ramkrishna.s.vasudevan commented on HBASE-9239:
---
Okie.. So +1 then. Thanks Ted.
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-tabpanel&focusedCommentId=13741880#comment-13741880
]
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/12598350/HBASE-7709-rev2.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/6775//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
> Fix For: 0.98.0, 0.94.12, 0.96.0
>
> Attachments: HBASE-7709.patch, HBASE-7709-rev1.patch,
> HBASE-7709-rev2.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-9203) Secondary index support through coprocessors
[ https://issues.apache.org/jira/browse/HBASE-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741875#comment-13741875 ] ramkrishna.s.vasudevan commented on HBASE-9203: --- bq.What potential bug may exist in IndexHalfStoreFileReader ? Some apis were not implemented. Those things needs to be revisited. >>For TestIndexRegionObserver, what does testHDP2938 cover ? Yes, renaming would be necessary. Some internal github issue has been raised for the same. [~lhofhansl] bq.Even if we add these there would be some other kernel changes, though, right? Yes there are few more. In the kernel patch attached check for HRegion, SplitTransaction, and some client side changes. > Secondary index support through coprocessors > > > Key: HBASE-9203 > URL: https://issues.apache.org/jira/browse/HBASE-9203 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.98.0 >Reporter: rajeshbabu >Assignee: rajeshbabu > > We have been working on implementing secondary index in HBase and open > sourced on hbase 0.94.8 version. > The project is available on github. > https://github.com/Huawei-Hadoop/hindex > This Jira is to support secondary index on trunk(0.98). > Following features will be supported. > - multiple indexes on table, > - multi column index, > - index based on part of a column value, > - equals and range condition scans using index, and > - bulk loading data to indexed table (Indexing done with bulk load) > Most of the kernel changes needed for secondary index is available in trunk. > Very minimal changes needed for it. -- 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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741877#comment-13741877
]
Ted Yu commented on HBASE-9239:
---
I think implementation for namespace is complete.
So no new entry would be added, I assume.
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-9237) Integration test cleanup after ChaosMonkey refactor
[
https://issues.apache.org/jira/browse/HBASE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741878#comment-13741878
]
Hadoop QA commented on HBASE-9237:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12598348/HBASE-9237-2.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 17 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:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6774//console
This message is automatically generated.
> Integration test cleanup after ChaosMonkey refactor
> ---
>
> Key: HBASE-9237
> URL: https://issues.apache.org/jira/browse/HBASE-9237
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.98.0, 0.96.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Attachments: HBASE-9237-0.patch, HBASE-9237-1.patch,
> HBASE-9237-2.patch
>
>
> Otherwise some mr based tests fail.
--
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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741867#comment-13741867
]
ramkrishna.s.vasudevan commented on HBASE-9239:
---
Yes Ted. I read that javadoc. But anyother namespace entry could be added?
If so again this index may change. So i suggested that way.
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-6721) RegionServer Group based Assignment
[ https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741866#comment-13741866 ] Andrew Purtell commented on HBASE-6721: --- The current state of this issue is confusing. The parent is in 'Patch Available' state but seems stale. Subtask #3 has been committed to trunk/0.96 and 0.94. Other subtasks are resolved as 'Invalid'. We should at least have a release note describing what is going to be in 0.96 (and already in 0.94). What further work is going to be done here? What been abandoned? Has enough functionality been committed already to address the contributors' use case? Did something turn out to be problematic? Nothing more for 0.96 since [~stack] has frozen 0.95, correct? Nothing more need in 0.96 to support placing tables on certain regionservers only (will help with 0.96 to 0.98 migration story)? I can research the answers to my questions in commit history but maybe we can get an authoritative answer from [~avandana] or [~toffer]? > RegionServer Group based Assignment > --- > > Key: HBASE-6721 > URL: https://issues.apache.org/jira/browse/HBASE-6721 > Project: HBase > Issue Type: New Feature >Reporter: Francis Liu >Assignee: Vandana Ayyalasomayajula > Fix For: 0.96.0 > > Attachments: 6721-master-webUI.patch, HBASE-6721_10.patch, > HBASE-6721_8.patch, HBASE-6721_94_2.patch, HBASE-6721_94_3.patch, > HBASE-6721_94_3.patch, HBASE-6721_94_4.patch, HBASE-6721_94_5.patch, > HBASE-6721_94_6.patch, HBASE-6721_94_7.patch, HBASE-6721_94.patch, > HBASE-6721_94.patch, HBASE-6721_9.patch, HBASE-6721_9.patch, > HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, > HBASE-6721-DesigDoc.pdf, HBASE-6721_trunk.patch, HBASE-6721_trunk.patch, > HBASE-6721_trunk.patch > > > In multi-tenant deployments of HBase, it is likely that a RegionServer will > be serving out regions from a number of different tables owned by various > client applications. Being able to group a subset of running RegionServers > and assign specific tables to it, provides a client application a level of > isolation and resource allocation. > The proposal essentially is to have an AssignmentManager which is aware of > RegionServer groups and assigns tables to region servers based on groupings. > Load balancing will occur on a per group basis as well. > This is essentially a simplification of the approach taken in HBASE-4120. See > attached document. -- 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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741865#comment-13741865
]
Ted Yu commented on HBASE-9239:
---
I thought about extracting entries for the test tables.
However I think that is not needed because of the following (javadoc of
getBlockCacheColumnFamilySummaries()):
The contract of this interface is to return the List in sorted order by Table
name, then ColumnFamily.
Meaning the test tables would always follow namespace table in the list.
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741864#comment-13741864
]
ramkrishna.s.vasudevan commented on HBASE-9239:
---
@Ted
Patch is good.
I have a suggestion, from the logs could see that the NameSpaceJanitor issues a
scan on the Meta and that includes Namespace into the blockcache summary.
>From code am not getting where the scan is happening through NameSpaceJanitor.
>
May be instead working with the index, we can just check if the testTable and
testTable2 are available in the list that we are checking.
If the catalog janitor adds any other namespace entries this may fail? So we
will check if the list contains those two tables then it may be easier.
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741859#comment-13741859
]
Hudson commented on HBASE-9023:
---
FAILURE: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #679 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/679/])
HBASE-9023 TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally
fails (tedyu: rev 1514538)
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
>
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 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] [Commented] (HBASE-9194) Break HMaster metrics into multiple contexts
[ https://issues.apache.org/jira/browse/HBASE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741856#comment-13741856 ] Hudson commented on HBASE-9194: --- SUCCESS: Integrated in hbase-0.95 #456 (See [https://builds.apache.org/job/hbase-0.95/456/]) HBASE-9194 Break HMaster metrics into multiple contexts (eclark: rev 1514514) * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystemSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSource.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java.orig * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManager.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMaster.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystem.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshot.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/BaseLoadBalancer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/CloneSnapshotHandler.java * /h
[jira] [Commented] (HBASE-9238) bug in Mutation::getFamilyMap
[ https://issues.apache.org/jira/browse/HBASE-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741854#comment-13741854 ] Sergey Shelukhin commented on HBASE-9238: - Ah well, this is 95-specific. I will get back to this tomorrow, need to see why the method is not on trunk also > bug in Mutation::getFamilyMap > - > > Key: HBASE-9238 > URL: https://issues.apache.org/jira/browse/HBASE-9238 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Fix For: 0.95.2 > > Attachments: HBASE-9238.patch > > > There's no comparator in the treemap, so if you try to get stuff out of it > there's a problem -- 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-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741852#comment-13741852
]
Hudson commented on HBASE-9236:
---
SUCCESS: Integrated in hbase-0.95-on-hadoop2 #246 (See
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/246/])
HBASE-9236 region_mover#getTable() should use TableName.toString() instead of
Bytes.toString() (tedyu: rev 1514553)
* /hbase/branches/0.95/bin/region_mover.rb
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-8659) LruBlockCache logs too much
[
https://issues.apache.org/jira/browse/HBASE-8659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741850#comment-13741850
]
Sergey Shelukhin commented on HBASE-8659:
-
Hm... maybe we can add some accumulation/timeout logic and put it back? My
point is that even in a semi-abnormal workload taking up 85% of the log with
these seems like a bad idea.
If anything there should be a metric to monitor it, with logs only for
drill-down
> LruBlockCache logs too much
> ---
>
> Key: HBASE-8659
> URL: https://issues.apache.org/jira/browse/HBASE-8659
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-8659-v0.patch
>
>
> LruBlockCache logs too much.
> {code}
> grep -c . hbase-hbase-regionserver-.log
> 77539
> grep -c LruBlockCache hbase-hbase-regionserver-..log
> 64459
> {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-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741851#comment-13741851
]
Hudson commented on HBASE-9023:
---
SUCCESS: Integrated in hbase-0.95-on-hadoop2 #246 (See
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/246/])
HBASE-9023 TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally
fails (tedyu: rev 1514550)
*
/hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
>
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 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] [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: HBASE-7709-rev2.patch Sorry for the confusion in the earlier emails. Yes, the test case was for A -> B -> C -> B. Attaching the patch for 0.94 (revision 2) > 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 > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: HBASE-7709.patch, HBASE-7709-rev1.patch, > HBASE-7709-rev2.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-9237) Integration test cleanup after ChaosMonkey refactor
[ https://issues.apache.org/jira/browse/HBASE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9237: - Attachment: HBASE-9237-2.patch > Integration test cleanup after ChaosMonkey refactor > --- > > Key: HBASE-9237 > URL: https://issues.apache.org/jira/browse/HBASE-9237 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.98.0, 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-9237-0.patch, HBASE-9237-1.patch, > HBASE-9237-2.patch > > > Otherwise some mr based tests fail. -- 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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741825#comment-13741825
]
Hadoop QA commented on HBASE-9239:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12598339/9239-v1.txt
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: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:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6772//console
This message is automatically generated.
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-9241) Add cp hook before initialize variable set to true in master intialization
rajeshbabu created HBASE-9241: - Summary: Add cp hook before initialize variable set to true in master intialization Key: HBASE-9241 URL: https://issues.apache.org/jira/browse/HBASE-9241 Project: HBase Issue Type: Sub-task Components: master Reporter: rajeshbabu This hook helps in following cases. 1) When we are creating indexed table then there is a chance that master can go down after successful creation of user table but index table creation not yet started. This hook helps to find such cases and create missing index table. 2) if any case there are mismatches in colocation of user and index regions we can run balancer. -- 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-9237) Integration test cleanup after ChaosMonkey refactor
[ https://issues.apache.org/jira/browse/HBASE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9237: - Attachment: HBASE-9237-1.patch > Integration test cleanup after ChaosMonkey refactor > --- > > Key: HBASE-9237 > URL: https://issues.apache.org/jira/browse/HBASE-9237 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.98.0, 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-9237-0.patch, HBASE-9237-1.patch > > > Otherwise some mr based tests fail. -- 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-9240) Use protobuf 2.5 features for improved performance
[ https://issues.apache.org/jira/browse/HBASE-9240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-9240: -- Description: Over on HADOOP-9876, Hadoop enumerates the benefits of protobuf 2.5.0. We have the same considerations for our RPC and elsewhere after HBASE-8165 (was: Over on HADOOP-9876, Hadoop enumerates the benefits of protobuf 2.5.0. We have the same considerations for our RPC after HBASE-8165) > Use protobuf 2.5 features for improved performance > -- > > Key: HBASE-9240 > URL: https://issues.apache.org/jira/browse/HBASE-9240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell > > Over on HADOOP-9876, Hadoop enumerates the benefits of protobuf 2.5.0. We > have the same considerations for our RPC and elsewhere after HBASE-8165 -- 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-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741811#comment-13741811
]
Ted Yu commented on HBASE-9236:
---
Just saw that.
bq. should also fix HBASE-8803
I think so.
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9240) Use protobuf 2.5 features for improved performance
Andrew Purtell created HBASE-9240: - Summary: Use protobuf 2.5 features for improved performance Key: HBASE-9240 URL: https://issues.apache.org/jira/browse/HBASE-9240 Project: HBase Issue Type: Improvement Reporter: Andrew Purtell Over on HADOOP-9876, Hadoop enumerates the benefits of protobuf 2.5.0. We have the same considerations for our RPC after HBASE-8165 -- 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-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741803#comment-13741803
]
Jean-Marc Spaggiari commented on HBASE-9236:
BTW, why are we not doing this directly into HBASE-8803? It's kind of
duplicate, no?
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741802#comment-13741802
]
Jean-Marc Spaggiari commented on HBASE-9236:
So that should also fix HBASE-8803, right?
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9237) Integration test cleanup after ChaosMonkey refactor
[ https://issues.apache.org/jira/browse/HBASE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9237: - Attachment: HBASE-9237-0.patch Chaos monkey other than Calm Monkey is broken in non-unit test IT test runs. > Integration test cleanup after ChaosMonkey refactor > --- > > Key: HBASE-9237 > URL: https://issues.apache.org/jira/browse/HBASE-9237 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.98.0, 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-9237-0.patch > > > Otherwise some mr based tests fail. -- 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-9237) Integration test cleanup after ChaosMonkey refactor
[ https://issues.apache.org/jira/browse/HBASE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9237: - Status: Patch Available (was: Open) > Integration test cleanup after ChaosMonkey refactor > --- > > Key: HBASE-9237 > URL: https://issues.apache.org/jira/browse/HBASE-9237 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.98.0, 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > Attachments: HBASE-9237-0.patch > > > Otherwise some mr based tests fail. -- 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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-9239:
--
Fix Version/s: 0.98.0
Status: Patch Available (was: Open)
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0
>
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741788#comment-13741788
]
Ted Yu commented on HBASE-9236:
---
Integrated to 0.95 and trunk.
Thanks for the review, Francis.
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9238) bug in Mutation::getFamilyMap
[
https://issues.apache.org/jira/browse/HBASE-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741790#comment-13741790
]
Hadoop QA commented on HBASE-9238:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12598332/HBASE-9238.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:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6773//console
This message is automatically generated.
> bug in Mutation::getFamilyMap
> -
>
> Key: HBASE-9238
> URL: https://issues.apache.org/jira/browse/HBASE-9238
> Project: HBase
> Issue Type: Bug
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
>Priority: Critical
> Fix For: 0.95.2
>
> Attachments: HBASE-9238.patch
>
>
> There's no comparator in the treemap, so if you try to get stuff out of it
> there's a problem
--
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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-9239:
--
Attachment: 9239-v1.txt
Patch v1 allows more than 2 BlockCacheColumnFamilySummary entries to be
retrieved.
Subsequent assertions work on the last two entries.
Test passed locally.
> TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
> ---
>
> Key: HBASE-9239
> URL: https://issues.apache.org/jira/browse/HBASE-9239
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 9239-v1.txt
>
>
> From
> https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
> {code}
> java.lang.AssertionError: blockCache summary has entries expected:<2> but
> was:<3>
> 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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
> {code}
> This was due to an additional entry for namespace table:
> {code}
> 2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
> regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
> [BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
> heapSize=512], BlockCacheSummaryEntry [table=testTable,
> columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
> [table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
> {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-9238) bug in Mutation::getFamilyMap
[ https://issues.apache.org/jira/browse/HBASE-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741775#comment-13741775 ] Sergey Shelukhin commented on HBASE-9238: - Will commit to trunk and 95 today unless there are objections > bug in Mutation::getFamilyMap > - > > Key: HBASE-9238 > URL: https://issues.apache.org/jira/browse/HBASE-9238 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Fix For: 0.95.2 > > Attachments: HBASE-9238.patch > > > There's no comparator in the treemap, so if you try to get stuff out of it > there's a problem -- 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-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741776#comment-13741776
]
Ted Yu commented on HBASE-9023:
---
Integrated to 0.95 as well.
> TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
>
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 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] [Updated] (HBASE-9238) bug in Mutation::getFamilyMap
[ https://issues.apache.org/jira/browse/HBASE-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-9238: Status: Patch Available (was: Open) > bug in Mutation::getFamilyMap > - > > Key: HBASE-9238 > URL: https://issues.apache.org/jira/browse/HBASE-9238 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Fix For: 0.95.2 > > Attachments: HBASE-9238.patch > > > There's no comparator in the treemap, so if you try to get stuff out of it > there's a problem -- 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-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741773#comment-13741773
]
Hudson commented on HBASE-9023:
---
SUCCESS: Integrated in HBase-TRUNK #4399 (See
[https://builds.apache.org/job/HBase-TRUNK/4399/])
HBASE-9023 TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally
fails (tedyu: rev 1514538)
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
>
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 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] [Commented] (HBASE-9194) Break HMaster metrics into multiple contexts
[ https://issues.apache.org/jira/browse/HBASE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741772#comment-13741772 ] Hudson commented on HBASE-9194: --- SUCCESS: Integrated in HBase-TRUNK #4399 (See [https://builds.apache.org/job/HBase-TRUNK/4399/]) HBASE-9194 Break HMaster metrics into multiple contexts (eclark: rev 1514513) * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystemSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSource.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManager.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMaster.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystem.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshot.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/BaseLoadBalancer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/CloneSnapshotHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/DisabledTableSnapshotHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/EnabledTableSnapshotHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/RestoreSnapshotHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache
[jira] [Commented] (HBASE-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741767#comment-13741767
]
Hadoop QA commented on HBASE-9236:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12598315/9236-v1.txt
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:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6771//console
This message is automatically generated.
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9239) TestStoreFileBlockCacheSummary#testBlockCacheSummary occasionally fails
Ted Yu created HBASE-9239:
-
Summary: TestStoreFileBlockCacheSummary#testBlockCacheSummary
occasionally fails
Key: HBASE-9239
URL: https://issues.apache.org/jira/browse/HBASE-9239
Project: HBase
Issue Type: Test
Reporter: Ted Yu
Assignee: Ted Yu
>From
>https://builds.apache.org/job/HBase-0.95/455/testReport/org.apache.hadoop.hbase.regionserver/TestStoreFileBlockCacheSummary/testBlockCacheSummary/
> :
{code}
java.lang.AssertionError: blockCache summary has entries expected:<2> but
was:<3>
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.apache.hadoop.hbase.regionserver.TestStoreFileBlockCacheSummary.testBlockCacheSummary(TestStoreFileBlockCacheSummary.java:112)
{code}
This was due to an additional entry for namespace table:
{code}
2013-08-16 00:24:25,337 INFO [pool-1-thread-1]
regionserver.TestStoreFileBlockCacheSummary(110): blockCacheSummary:
[BlockCacheSummaryEntry [table=namespace, columnFamily=info, blocks=1,
heapSize=512], BlockCacheSummaryEntry [table=testTable,
columnFamily=testFamily, blocks=1, heapSize=664], BlockCacheSummaryEntry
[table=testTable2, columnFamily=testFamily, blocks=1, heapSize=664]]
{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-9227) RESTServer should handle the loginUser correctly
[ https://issues.apache.org/jira/browse/HBASE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741763#comment-13741763 ] Hudson commented on HBASE-9227: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #678 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/678/]) HBASE-9227 RESTServer should handle the loginUser correctly (stack: rev 1514440) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/RESTServer.java > RESTServer should handle the loginUser correctly > > > Key: HBASE-9227 > URL: https://issues.apache.org/jira/browse/HBASE-9227 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.0 >Reporter: Devaraj Das >Assignee: Devaraj Das >Priority: Blocker > Fix For: 0.95.2 > > Attachments: 9227-1.txt, 9227-2.txt, 9227-3.txt, 9227-4.txt > > > HBASE-8662 introduced a change by which the realUser in the method > RESTServer.main() gets assigned to the loginUser only when the config > hbase.rest.authentication.type is set to something (like "kerberos"). > I think we should set the realUser to loginUser even when the config > hbase.rest.authentication.type is null. Without that the regular > (non-impersonated) accesses also fail. -- 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-9226) Thrift host and port are hardcoded in thrift2 DemoClient.java
[ https://issues.apache.org/jira/browse/HBASE-9226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741762#comment-13741762 ] Hudson commented on HBASE-9226: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #678 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/678/]) hbase-9226: Thrift host and port are hardcoded in thrift2 DemoClient.java (jeffreyz: rev 1514425) * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift2/DemoClient.java > Thrift host and port are hardcoded in thrift2 DemoClient.java > - > > Key: HBASE-9226 > URL: https://issues.apache.org/jira/browse/HBASE-9226 > Project: HBase > Issue Type: Bug >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong >Priority: Minor > Fix For: 0.98.0, 0.95.2 > > Attachments: hbase-9226.patch > > > The hard coded host of the client can only let it run on the same host as the > thrift server. -- 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-8667) Master and Regionserver not able to communicate if both bound to different network interfaces on the same machine.
[
https://issues.apache.org/jira/browse/HBASE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741760#comment-13741760
]
Hudson commented on HBASE-8667:
---
SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #678 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/678/])
HBASE-8667 Master and Regionserver not able to communicate if both bound to
different network interfaces on the same machine (stack: rev 1514427)
*
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
> Master and Regionserver not able to communicate if both bound to different
> network interfaces on the same machine.
> --
>
> Key: HBASE-8667
> URL: https://issues.apache.org/jira/browse/HBASE-8667
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Reporter: rajeshbabu
>Assignee: rajeshbabu
>Priority: Critical
> Fix For: 0.98.0, 0.95.2
>
> Attachments: HBASE-8667_trunk.patch, HBASE-8667_Trunk.patch,
> HBASE-8667_Trunk-V2.patch, HBASE-8667_trunk_v4.patch,
> HBASE-8667_trunk_v5.patch, HBASE-8667_trunk_v6.patch
>
>
> While testing HBASE-8640 fix found that master and regionserver running on
> different interfaces are not communicating properly.
> I have two interfaces 1) lo 2) eth0 in my machine and default hostname
> interface is lo.
> I have configured master ipc address to ip of eth0 interface.
> Started master and regionserver on the same machine.
> 1) master rpc server bound to eth0 and RS rpc server bound to lo
> 2) Since rpc client is not binding to any ip address, when RS is reporting RS
> startup its getting registered with eth0 ip address(but actually it should
> register localhost)
> Here are RS logs:
> {code}
> 2013-05-31 06:05:28,608 WARN [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: reportForDuty failed;
> sleeping and then retrying.
> 2013-05-31 06:05:31,609 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Attempting connect to
> Master server at 192.168.0.100,6,1369960497008
> 2013-05-31 06:05:31,609 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Telling master at
> 192.168.0.100,6,1369960497008 that we are up with port=60020,
> startcode=1369960502544
> 2013-05-31 06:05:31,618 DEBUG [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Config from master:
> hbase.rootdir=hdfs://localhost:2851/hbase
> 2013-05-31 06:05:31,618 DEBUG [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Config from master:
> fs.default.name=hdfs://localhost:2851
> 2013-05-31 06:05:31,618 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Master passed us a
> different hostname to use; was=localhost, but now=192.168.0.100
> {code}
> Here are master logs:
> {code}
> 2013-05-31 06:05:31,615 INFO [IPC Server handler 9 on 6]
> org.apache.hadoop.hbase.master.ServerManager: Registering
> server=192.168.0.100,60020,1369960502544
> {code}
> Since master has wrong rpc server address of RS, META is not getting assigned.
> {code}
> 2013-05-31 06:05:34,362 DEBUG [master-192.168.0.100,6,1369960497008]
> org.apache.hadoop.hbase.master.AssignmentManager: No previous transition plan
> was found (or we are ignoring an existing plan) for .META.,,1.1028785192 so
> generated a random one; hri=.META.,,1.1028785192, src=,
> dest=192.168.0.100,60020,1369960502544; 1 (online=1, available=1) available
> servers, forceNewPlan=false
> -
> org.apache.hadoop.hbase.master.AssignmentManager: Failed assignment of
> .META.,,1.1028785192 to 192.168.0.100,60020,1369960502544, trying to assign
> elsewhere instead; try=1 of 10
> java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:592)
> at
> org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)
> at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:511)
> at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:481)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.setupConnection(RpcClient.java:549)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.setupIOstreams(RpcClient.java:813)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.getConnection(RpcClient.java:1422)
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1315)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1532)
> at
[jira] [Commented] (HBASE-9164) Convert List anti pattern to List pattern.
[ https://issues.apache.org/jira/browse/HBASE-9164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741761#comment-13741761 ] Hudson commented on HBASE-9164: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #678 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/678/]) HBASE-9164 Convert List anti pattern to List pattern This patch also starts a refactor of the KVComparator. (jmhsieh: rev 1514400) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Append.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTable.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Increment.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/ProtobufUtil.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValue.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/PutCombiner.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/PutSortReducer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/protobuf/ReplicationProtbufUtil.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MemStore.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/MultiRowMutationProcessor.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/thrift2/ThriftUtilities.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/SimpleRegionObserver.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverBypass.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestWALObserver.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/protobuf/TestReplicationProtobuf.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/HLogPerformanceEvaluation.java > Convert List anti pattern to List pattern. > > > Key: HBASE-9164 > URL: https://issues.apache.org/jira/browse/HBASE-9164 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.95.1 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh >Priority: Blocker > Fix For: 0.95.2, 0.96.0 > > Attachments: hbase-9164.patch, hbase-9164.v2-95.patch, > hbase-9164.v2.patch > > > As described in HBASE-9142, using List is an anti pattern > that adds unnecessary typing and casting clutter to the code base. It would > be best to remove this before we release 0.95.2 or 0.96. -- 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-9232) Fix javadoc warning and a few findbugs items.
[ https://issues.apache.org/jira/browse/HBASE-9232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741758#comment-13741758 ] Hudson commented on HBASE-9232: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #678 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/678/]) HBASE-9232 Fix javadoc warning and a few findbugs items (stack: rev 1514309) * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RpcRetryingCaller.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/security/access/TablePermission.java > Fix javadoc warning and a few findbugs items. > - > > Key: HBASE-9232 > URL: https://issues.apache.org/jira/browse/HBASE-9232 > Project: HBase > Issue Type: Bug > Components: test >Reporter: stack >Assignee: stack > Fix For: 0.98.0, 0.95.2 > > Attachments: 9232.txt, 9232v2.txt > > > Findbugs and javadoc are complaining in hadoopqa builds. Try and fix. -- 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-9222) Thrift DemoClient failed with error IllegalArgument(message:Row length is 0)
[
https://issues.apache.org/jira/browse/HBASE-9222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741757#comment-13741757
]
Hudson commented on HBASE-9222:
---
SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #678 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/678/])
hbase-9222: Thrift DemoClient failed with error IllegalArgument(message:Row
length is 0) (jeffreyz: rev 1514401)
*
/hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/DemoClient.java
> Thrift DemoClient failed with error IllegalArgument(message:Row length is 0)
>
>
> Key: HBASE-9222
> URL: https://issues.apache.org/jira/browse/HBASE-9222
> Project: HBase
> Issue Type: Bug
>Reporter: Jeffrey Zhong
>Assignee: Jeffrey Zhong
>Priority: Minor
> Attachments: hbase-9222.patch
>
>
> We make it illegal passing null row to Put/Delete from hbase-8101. While
> Thrift demo client still verify empty row situation as following:
> {code}
> // try empty strings
> mutations = new ArrayList();
> mutations.add(new Mutation(false, ByteBuffer.wrap(bytes("entry:")),
> ByteBuffer.wrap(bytes("")), writeToWal));
> client.mutateRow(ByteBuffer.wrap(t), ByteBuffer.wrap(bytes("")),
> mutations, dummyAttributes);
> {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-9194) Break HMaster metrics into multiple contexts
[ https://issues.apache.org/jira/browse/HBASE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741759#comment-13741759 ] Hudson commented on HBASE-9194: --- SUCCESS: Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #678 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/678/]) HBASE-9194 Break HMaster metrics into multiple contexts (eclark: rev 1514513) * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystemSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSource.java * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/trunk/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSource.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/trunk/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/trunk/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManager.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMaster.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystem.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshot.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/BaseLoadBalancer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/CloneSnapshotHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/DisabledTableSnapshotHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/EnabledTableSnapshotHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/RestoreSnapshotHandler.java * /hbase/trunk/hbase-s
[jira] [Commented] (HBASE-8165) Update our protobuf to 2.5 from 2.4.1
[ https://issues.apache.org/jira/browse/HBASE-8165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741748#comment-13741748 ] Sergey Shelukhin commented on HBASE-8165: - Trunk patch is very similar to 95, except that protobuf stuff has to be regenned. I am not adding it or submitting to HadoopQA because w/o 2.1.0 it won't work anyway. > Update our protobuf to 2.5 from 2.4.1 > - > > Key: HBASE-8165 > URL: https://issues.apache.org/jira/browse/HBASE-8165 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 0.98.0, 0.96.0 > > Attachments: 8165.txt, 8165v2.txt, 8165v3.txt, 8165v4.txt, > 8165v5.txt, HBASE-8165-rebased.patch > > > Update to new 2.5 pb. Some speedups and a new PARSER idiom that bypasses > making a builder. -- 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-9194) Break HMaster metrics into multiple contexts
[ https://issues.apache.org/jira/browse/HBASE-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741751#comment-13741751 ] Hudson commented on HBASE-9194: --- FAILURE: Integrated in hbase-0.95-on-hadoop2 #245 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/245/]) HBASE-9194 Break HMaster metrics into multiple contexts (eclark: rev 1514514) * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystemSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSource.java * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/branches/0.95/hbase-hadoop-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSource.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManagerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFilesystemSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshotSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancerSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsAssignmentManagerSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsMasterFileSystemSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.MetricsSnapshotSource * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/resources/META-INF/services/org.apache.hadoop.hbase.master.balancer.MetricsBalancerSource * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java.orig * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterFileSystem.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsAssignmentManager.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMaster.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsMasterFileSystem.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/MetricsSnapshot.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/BaseLoadBalancer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/MetricsBalancer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/snapshot/CloneSnap
[jira] [Commented] (HBASE-8165) Update our protobuf to 2.5 from 2.4.1
[ https://issues.apache.org/jira/browse/HBASE-8165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741742#comment-13741742 ] Sergey Shelukhin commented on HBASE-8165: - Note that this also switched hadoop2 profile to use 2.1.0-beta > Update our protobuf to 2.5 from 2.4.1 > - > > Key: HBASE-8165 > URL: https://issues.apache.org/jira/browse/HBASE-8165 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 0.98.0, 0.96.0 > > Attachments: 8165.txt, 8165v2.txt, 8165v3.txt, 8165v4.txt, > 8165v5.txt, HBASE-8165-rebased.patch > > > Update to new 2.5 pb. Some speedups and a new PARSER idiom that bypasses > making a builder. -- 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-8165) Update our protobuf to 2.5 from 2.4.1
[ https://issues.apache.org/jira/browse/HBASE-8165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-8165: Attachment: HBASE-8165-rebased.patch Rebased patch for 95 > Update our protobuf to 2.5 from 2.4.1 > - > > Key: HBASE-8165 > URL: https://issues.apache.org/jira/browse/HBASE-8165 > Project: HBase > Issue Type: Bug >Reporter: stack >Assignee: stack > Fix For: 0.98.0, 0.96.0 > > Attachments: 8165.txt, 8165v2.txt, 8165v3.txt, 8165v4.txt, > 8165v5.txt, HBASE-8165-rebased.patch > > > Update to new 2.5 pb. Some speedups and a new PARSER idiom that bypasses > making a builder. -- 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-9226) Thrift host and port are hardcoded in thrift2 DemoClient.java
[ https://issues.apache.org/jira/browse/HBASE-9226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741732#comment-13741732 ] Hudson commented on HBASE-9226: --- FAILURE: Integrated in hbase-0.95 #455 (See [https://builds.apache.org/job/hbase-0.95/455/]) hbase-9226: Thrift host and port are hardcoded in thrift2 DemoClient.java (jeffreyz: rev 1514428) * /hbase/branches/0.95/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift2/DemoClient.java > Thrift host and port are hardcoded in thrift2 DemoClient.java > - > > Key: HBASE-9226 > URL: https://issues.apache.org/jira/browse/HBASE-9226 > Project: HBase > Issue Type: Bug >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong >Priority: Minor > Fix For: 0.98.0, 0.95.2 > > Attachments: hbase-9226.patch > > > The hard coded host of the client can only let it run on the same host as the > thrift server. -- 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-9227) RESTServer should handle the loginUser correctly
[ https://issues.apache.org/jira/browse/HBASE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741733#comment-13741733 ] Hudson commented on HBASE-9227: --- FAILURE: Integrated in hbase-0.95 #455 (See [https://builds.apache.org/job/hbase-0.95/455/]) HBASE-9227 RESTServer should handle the loginUser correctly (stack: rev 1514439) * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/RESTServer.java > RESTServer should handle the loginUser correctly > > > Key: HBASE-9227 > URL: https://issues.apache.org/jira/browse/HBASE-9227 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.0 >Reporter: Devaraj Das >Assignee: Devaraj Das >Priority: Blocker > Fix For: 0.95.2 > > Attachments: 9227-1.txt, 9227-2.txt, 9227-3.txt, 9227-4.txt > > > HBASE-8662 introduced a change by which the realUser in the method > RESTServer.main() gets assigned to the loginUser only when the config > hbase.rest.authentication.type is set to something (like "kerberos"). > I think we should set the realUser to loginUser even when the config > hbase.rest.authentication.type is null. Without that the regular > (non-impersonated) accesses also fail. -- 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-8667) Master and Regionserver not able to communicate if both bound to different network interfaces on the same machine.
[
https://issues.apache.org/jira/browse/HBASE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741731#comment-13741731
]
Hudson commented on HBASE-8667:
---
FAILURE: Integrated in hbase-0.95 #455 (See
[https://builds.apache.org/job/hbase-0.95/455/])
HBASE-8667 Master and Regionserver not able to communicate if both bound to
different network interfaces on the same machine (stack: rev 1514426)
*
/hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
*
/hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
> Master and Regionserver not able to communicate if both bound to different
> network interfaces on the same machine.
> --
>
> Key: HBASE-8667
> URL: https://issues.apache.org/jira/browse/HBASE-8667
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Reporter: rajeshbabu
>Assignee: rajeshbabu
>Priority: Critical
> Fix For: 0.98.0, 0.95.2
>
> Attachments: HBASE-8667_trunk.patch, HBASE-8667_Trunk.patch,
> HBASE-8667_Trunk-V2.patch, HBASE-8667_trunk_v4.patch,
> HBASE-8667_trunk_v5.patch, HBASE-8667_trunk_v6.patch
>
>
> While testing HBASE-8640 fix found that master and regionserver running on
> different interfaces are not communicating properly.
> I have two interfaces 1) lo 2) eth0 in my machine and default hostname
> interface is lo.
> I have configured master ipc address to ip of eth0 interface.
> Started master and regionserver on the same machine.
> 1) master rpc server bound to eth0 and RS rpc server bound to lo
> 2) Since rpc client is not binding to any ip address, when RS is reporting RS
> startup its getting registered with eth0 ip address(but actually it should
> register localhost)
> Here are RS logs:
> {code}
> 2013-05-31 06:05:28,608 WARN [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: reportForDuty failed;
> sleeping and then retrying.
> 2013-05-31 06:05:31,609 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Attempting connect to
> Master server at 192.168.0.100,6,1369960497008
> 2013-05-31 06:05:31,609 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Telling master at
> 192.168.0.100,6,1369960497008 that we are up with port=60020,
> startcode=1369960502544
> 2013-05-31 06:05:31,618 DEBUG [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Config from master:
> hbase.rootdir=hdfs://localhost:2851/hbase
> 2013-05-31 06:05:31,618 DEBUG [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Config from master:
> fs.default.name=hdfs://localhost:2851
> 2013-05-31 06:05:31,618 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Master passed us a
> different hostname to use; was=localhost, but now=192.168.0.100
> {code}
> Here are master logs:
> {code}
> 2013-05-31 06:05:31,615 INFO [IPC Server handler 9 on 6]
> org.apache.hadoop.hbase.master.ServerManager: Registering
> server=192.168.0.100,60020,1369960502544
> {code}
> Since master has wrong rpc server address of RS, META is not getting assigned.
> {code}
> 2013-05-31 06:05:34,362 DEBUG [master-192.168.0.100,6,1369960497008]
> org.apache.hadoop.hbase.master.AssignmentManager: No previous transition plan
> was found (or we are ignoring an existing plan) for .META.,,1.1028785192 so
> generated a random one; hri=.META.,,1.1028785192, src=,
> dest=192.168.0.100,60020,1369960502544; 1 (online=1, available=1) available
> servers, forceNewPlan=false
> -
> org.apache.hadoop.hbase.master.AssignmentManager: Failed assignment of
> .META.,,1.1028785192 to 192.168.0.100,60020,1369960502544, trying to assign
> elsewhere instead; try=1 of 10
> java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:592)
> at
> org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)
> at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:511)
> at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:481)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.setupConnection(RpcClient.java:549)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.setupIOstreams(RpcClient.java:813)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.getConnection(RpcClient.java:1422)
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1315)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1532)
> at
> org.apache.had
[jira] [Commented] (HBASE-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741724#comment-13741724
]
Ted Yu commented on HBASE-9236:
---
Yeah, the two methods return the same field.
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9236) region_mover#getTable() should use TableName.toString() instead of Bytes.toString()
[
https://issues.apache.org/jira/browse/HBASE-9236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741720#comment-13741720
]
Francis Liu commented on HBASE-9236:
+1 (non-binding)
toString() or getNameAsString() should work.
> region_mover#getTable() should use TableName.toString() instead of
> Bytes.toString()
> ---
>
> Key: HBASE-9236
> URL: https://issues.apache.org/jira/browse/HBASE-9236
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 9236-v1.txt
>
>
> region_mover#getTable() has the following code:
> {code}
> key = Bytes.toString(name)
> {code}
> where name is TableName. However there is no Bytes.toString(TableName)
> defined.
> TableName.toString() should be used instead.
--
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-9238) bug in Mutation::getFamilyMap
[ https://issues.apache.org/jira/browse/HBASE-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741721#comment-13741721 ] Ted Yu commented on HBASE-9238: --- +1 > bug in Mutation::getFamilyMap > - > > Key: HBASE-9238 > URL: https://issues.apache.org/jira/browse/HBASE-9238 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Fix For: 0.95.2 > > Attachments: HBASE-9238.patch > > > There's no comparator in the treemap, so if you try to get stuff out of it > there's a problem -- 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-9238) bug in Mutation::getFamilyMap
[ https://issues.apache.org/jira/browse/HBASE-9238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Shelukhin updated HBASE-9238: Attachment: HBASE-9238.patch patch. > bug in Mutation::getFamilyMap > - > > Key: HBASE-9238 > URL: https://issues.apache.org/jira/browse/HBASE-9238 > Project: HBase > Issue Type: Bug >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Critical > Fix For: 0.95.2 > > Attachments: HBASE-9238.patch > > > There's no comparator in the treemap, so if you try to get stuff out of it > there's a problem -- 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-9238) bug in Mutation::getFamilyMap
Sergey Shelukhin created HBASE-9238: --- Summary: bug in Mutation::getFamilyMap Key: HBASE-9238 URL: https://issues.apache.org/jira/browse/HBASE-9238 Project: HBase Issue Type: Bug Reporter: Sergey Shelukhin Assignee: Sergey Shelukhin Priority: Critical Fix For: 0.95.2 There's no comparator in the treemap, so if you try to get stuff out of it there's a problem -- 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-9237) Integration test cleanup after ChaosMonkey refactor
[ https://issues.apache.org/jira/browse/HBASE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9237: - Summary: Integration test cleanup after ChaosMonkey refactor (was: Integration tests need to addDependencyJars for hbase-server) > Integration test cleanup after ChaosMonkey refactor > --- > > Key: HBASE-9237 > URL: https://issues.apache.org/jira/browse/HBASE-9237 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.98.0, 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > > Otherwise some mr based tests fail. -- 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-9208) ReplicationLogCleaner slow at large scale
[
https://issues.apache.org/jira/browse/HBASE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741683#comment-13741683
]
Hadoop QA commented on HBASE-9208:
--
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12598300/HBASE-9208.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: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:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6770//console
This message is automatically generated.
> ReplicationLogCleaner slow at large scale
> -
>
> Key: HBASE-9208
> URL: https://issues.apache.org/jira/browse/HBASE-9208
> Project: HBase
> Issue Type: Improvement
>Reporter: Dave Latham
>Assignee: Dave Latham
> Fix For: 0.94.12, 0.96.0
>
> Attachments: HBASE-9208.patch
>
>
> At a large scale the ReplicationLogCleaner fails to clean up .oldlogs as fast
> as the cluster is producing them. For each old HLog file that has been
> replicated and should be deleted the ReplicationLogCleaner checks every
> replication queue in ZooKeeper before removing it. This means that as a
> cluster scales up the number of files to delete scales as well as the time to
> delete each file so the cleanup chore scales quadratically. In our case it
> reached the point where the oldlogs were growing faster than they were being
> cleaned up.
> We're now running with a patch that allows the ReplicationLogCleaner to
> refresh its list of files in the replication queues from ZooKeeper just once
> for each batch of files the CleanerChore wants to evaluate.
> I'd propose updating FileCleanerDelegate to take a List rather
> than a single one at a time. This would allow file cleaners that check an
> external resource for references such as ZooKeeper (for
> ReplicationLogCleaner) or HDFS (for SnapshotLogCleaner which looks like it
> may also have similar trouble at scale) to load those references once per
> batch rather than for every log.
--
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-9237) Integration tests need to addDependencyJars for hbase-server
Elliott Clark created HBASE-9237: Summary: Integration tests need to addDependencyJars for hbase-server Key: HBASE-9237 URL: https://issues.apache.org/jira/browse/HBASE-9237 Project: HBase Issue Type: Bug Components: test Affects Versions: 0.98.0, 0.96.0 Reporter: Elliott Clark Assignee: Elliott Clark Otherwise some mr based tests fail. -- 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-9237) Integration tests need to addDependencyJars for hbase-server
[ https://issues.apache.org/jira/browse/HBASE-9237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-9237: - Priority: Critical (was: Major) > Integration tests need to addDependencyJars for hbase-server > > > Key: HBASE-9237 > URL: https://issues.apache.org/jira/browse/HBASE-9237 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 0.98.0, 0.96.0 >Reporter: Elliott Clark >Assignee: Elliott Clark >Priority: Critical > > Otherwise some mr based tests fail. -- 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-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741656#comment-13741656
]
Ted Yu commented on HBASE-9023:
---
Integrated to trunk.
Will watch Jenkins builds for related test failure.
> TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
>
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 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] [Updated] (HBASE-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-9023:
--
Summary: TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally
fails (was: TestIOFencing.testFencingAroundCompactionAfterWALSync)
> TestIOFencing.testFencingAroundCompactionAfterWALSync occasionally fails
>
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 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] [Commented] (HBASE-9226) Thrift host and port are hardcoded in thrift2 DemoClient.java
[ https://issues.apache.org/jira/browse/HBASE-9226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741653#comment-13741653 ] Hudson commented on HBASE-9226: --- SUCCESS: Integrated in HBase-TRUNK #4398 (See [https://builds.apache.org/job/HBase-TRUNK/4398/]) hbase-9226: Thrift host and port are hardcoded in thrift2 DemoClient.java (jeffreyz: rev 1514425) * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift2/DemoClient.java > Thrift host and port are hardcoded in thrift2 DemoClient.java > - > > Key: HBASE-9226 > URL: https://issues.apache.org/jira/browse/HBASE-9226 > Project: HBase > Issue Type: Bug >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong >Priority: Minor > Fix For: 0.98.0, 0.95.2 > > Attachments: hbase-9226.patch > > > The hard coded host of the client can only let it run on the same host as the > thrift server. -- 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-9227) RESTServer should handle the loginUser correctly
[ https://issues.apache.org/jira/browse/HBASE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741654#comment-13741654 ] Hudson commented on HBASE-9227: --- SUCCESS: Integrated in HBase-TRUNK #4398 (See [https://builds.apache.org/job/HBase-TRUNK/4398/]) HBASE-9227 RESTServer should handle the loginUser correctly (stack: rev 1514440) * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/rest/RESTServer.java > RESTServer should handle the loginUser correctly > > > Key: HBASE-9227 > URL: https://issues.apache.org/jira/browse/HBASE-9227 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.0 >Reporter: Devaraj Das >Assignee: Devaraj Das >Priority: Blocker > Fix For: 0.95.2 > > Attachments: 9227-1.txt, 9227-2.txt, 9227-3.txt, 9227-4.txt > > > HBASE-8662 introduced a change by which the realUser in the method > RESTServer.main() gets assigned to the loginUser only when the config > hbase.rest.authentication.type is set to something (like "kerberos"). > I think we should set the realUser to loginUser even when the config > hbase.rest.authentication.type is null. Without that the regular > (non-impersonated) accesses also fail. -- 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-8667) Master and Regionserver not able to communicate if both bound to different network interfaces on the same machine.
[
https://issues.apache.org/jira/browse/HBASE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741652#comment-13741652
]
Hudson commented on HBASE-8667:
---
SUCCESS: Integrated in HBase-TRUNK #4398 (See
[https://builds.apache.org/job/HBase-TRUNK/4398/])
HBASE-8667 Master and Regionserver not able to communicate if both bound to
different network interfaces on the same machine (stack: rev 1514427)
*
/hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/ipc/RpcClient.java
*
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
> Master and Regionserver not able to communicate if both bound to different
> network interfaces on the same machine.
> --
>
> Key: HBASE-8667
> URL: https://issues.apache.org/jira/browse/HBASE-8667
> Project: HBase
> Issue Type: Bug
> Components: IPC/RPC
>Reporter: rajeshbabu
>Assignee: rajeshbabu
>Priority: Critical
> Fix For: 0.98.0, 0.95.2
>
> Attachments: HBASE-8667_trunk.patch, HBASE-8667_Trunk.patch,
> HBASE-8667_Trunk-V2.patch, HBASE-8667_trunk_v4.patch,
> HBASE-8667_trunk_v5.patch, HBASE-8667_trunk_v6.patch
>
>
> While testing HBASE-8640 fix found that master and regionserver running on
> different interfaces are not communicating properly.
> I have two interfaces 1) lo 2) eth0 in my machine and default hostname
> interface is lo.
> I have configured master ipc address to ip of eth0 interface.
> Started master and regionserver on the same machine.
> 1) master rpc server bound to eth0 and RS rpc server bound to lo
> 2) Since rpc client is not binding to any ip address, when RS is reporting RS
> startup its getting registered with eth0 ip address(but actually it should
> register localhost)
> Here are RS logs:
> {code}
> 2013-05-31 06:05:28,608 WARN [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: reportForDuty failed;
> sleeping and then retrying.
> 2013-05-31 06:05:31,609 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Attempting connect to
> Master server at 192.168.0.100,6,1369960497008
> 2013-05-31 06:05:31,609 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Telling master at
> 192.168.0.100,6,1369960497008 that we are up with port=60020,
> startcode=1369960502544
> 2013-05-31 06:05:31,618 DEBUG [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Config from master:
> hbase.rootdir=hdfs://localhost:2851/hbase
> 2013-05-31 06:05:31,618 DEBUG [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Config from master:
> fs.default.name=hdfs://localhost:2851
> 2013-05-31 06:05:31,618 INFO [regionserver60020]
> org.apache.hadoop.hbase.regionserver.HRegionServer: Master passed us a
> different hostname to use; was=localhost, but now=192.168.0.100
> {code}
> Here are master logs:
> {code}
> 2013-05-31 06:05:31,615 INFO [IPC Server handler 9 on 6]
> org.apache.hadoop.hbase.master.ServerManager: Registering
> server=192.168.0.100,60020,1369960502544
> {code}
> Since master has wrong rpc server address of RS, META is not getting assigned.
> {code}
> 2013-05-31 06:05:34,362 DEBUG [master-192.168.0.100,6,1369960497008]
> org.apache.hadoop.hbase.master.AssignmentManager: No previous transition plan
> was found (or we are ignoring an existing plan) for .META.,,1.1028785192 so
> generated a random one; hri=.META.,,1.1028785192, src=,
> dest=192.168.0.100,60020,1369960502544; 1 (online=1, available=1) available
> servers, forceNewPlan=false
> -
> org.apache.hadoop.hbase.master.AssignmentManager: Failed assignment of
> .META.,,1.1028785192 to 192.168.0.100,60020,1369960502544, trying to assign
> elsewhere instead; try=1 of 10
> java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:592)
> at
> org.apache.hadoop.net.SocketIOWithTimeout.connect(SocketIOWithTimeout.java:206)
> at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:511)
> at org.apache.hadoop.net.NetUtils.connect(NetUtils.java:481)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.setupConnection(RpcClient.java:549)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.setupIOstreams(RpcClient.java:813)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.getConnection(RpcClient.java:1422)
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1315)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1532)
> at
> org.apache.hadoop.hbase.ip
[jira] [Updated] (HBASE-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-9023:
--
Fix Version/s: 0.98.0
Hadoop Flags: Reviewed
> TestIOFencing.testFencingAroundCompactionAfterWALSync
> -
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 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] [Commented] (HBASE-9023) TestIOFencing.testFencingAroundCompactionAfterWALSync
[
https://issues.apache.org/jira/browse/HBASE-9023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741646#comment-13741646
]
Ted Yu commented on HBASE-9023:
---
>From https://builds.apache.org/job/PreCommit-HBASE-Build/6767/console :
{code}
HBASE-9023 patch is being downloaded at Thu Aug 15 22:04:37 UTC 2013 from
http://issues.apache.org/jira/secure/attachment/12598280/9023-v1.txt
...
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected
termination of the channel
hudson.remoting.RequestAbortedException:
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected
termination of the channel
at
hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
at
hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
{code}
Don't know what caused the abort.
> TestIOFencing.testFencingAroundCompactionAfterWALSync
> -
>
> Key: HBASE-9023
> URL: https://issues.apache.org/jira/browse/HBASE-9023
> Project: HBase
> Issue Type: Bug
> Components: test
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.96.0
>
> Attachments: 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
