[jira] [Updated] (HBASE-9116) Add a view/edit tool for favored node mappings for regions
[ https://issues.apache.org/jira/browse/HBASE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Devaraj Das updated HBASE-9116: --- Attachment: 9116-4.txt Added tests for verifying assignment when RSs are lost (regions for which this RS was primary should move to the secondaries). > Add a view/edit tool for favored node mappings for regions > -- > > Key: HBASE-9116 > URL: https://issues.apache.org/jira/browse/HBASE-9116 > Project: HBase > Issue Type: Improvement > Components: Region Assignment >Affects Versions: 0.95.0 >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.96.0 > > Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt, > 9116-3.txt, 9116-4.txt > > > Add a tool that one can run offline to view the favored node mappings for > regions, and also fix the mappings if needed. Such a tool exists in the > 0.89-fb branch. Will port it over to trunk/0.95. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9305) [0.92] TestFromClientSide.testCacheOnWriteEvictOnClose fails occasionally
[
https://issues.apache.org/jira/browse/HBASE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-9305:
--
Attachment: 9305.patch
Triage by not checking hit counts at the problematic point in the test. May
just move the problem. Testing.
> [0.92] TestFromClientSide.testCacheOnWriteEvictOnClose fails occasionally
> -
>
> Key: HBASE-9305
> URL: https://issues.apache.org/jira/browse/HBASE-9305
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Attachments: 9305.patch
>
>
> The assertion failures are like this:
> {noformat}
> java.lang.AssertionError: expected:<2089> but was:<2109>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.hadoop.hbase.client.TestFromClientSide.testCacheOnWriteEvictOnClose(TestFromClientSide.java:4248)
> {noformat}
> Also:
> {noformat}
> expected:<2067> but was:<2087>
> {noformat}
> {noformat}
> expected:<2070> but was:<2090>
> {noformat}
> The test saves off the current block cache stats - block count and hits and
> misses - then puts a value and gets it back:
> {code}
> 4242: Put put = new Put(ROW);
> 4243: put.add(FAMILY, QUALIFIER, data);
> 4244: table.put(put);
> 4245: assertTrue(Bytes.equals(table.get(new Get(ROW)).value(), data));
> {code}
> then we have these asserts:
> {code}
> 4246: //data was in memstore so don't expect any changes
> 4247: assertEquals(startBlockCount, cache.getBlockCount());
> 4248: assertEquals(startBlockHits, cache.getStats().getHitCount());
> 4249: assertEquals(startBlockMiss, cache.getStats().getMissCount());
> {code}
> There are exactly 20 more hits than expected every time. In the log looks
> like there's a meta scan happening around the same time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-9304) [0.92] TestDrainingServer fails occasionally
[
https://issues.apache.org/jira/browse/HBASE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-9304.
---
Resolution: Fixed
Fix Version/s: 0.92.3
> [0.92] TestDrainingServer fails occasionally
>
>
> Key: HBASE-9304
> URL: https://issues.apache.org/jira/browse/HBASE-9304
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 0.92.3
>
> Attachments: 9304.patch
>
>
> The error is the same in every case:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:48)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertFalse(Assert.java:34)
> at junit.framework.Assert.assertFalse(Assert.java:41)
> at
> org.apache.hadoop.hbase.TestDrainingServer.setUpBeforeClass(TestDrainingServer.java:78)
> {noformat}
> This is a check at test startup that every regionserver has an assignment.
> Looks like sometimes it takes a long time for the cluster to come up - there
> are 5 RSes started - and not all get region assignments. Probably a test only
> fix here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9304) [0.92] TestDrainingServer fails occasionally
[
https://issues.apache.org/jira/browse/HBASE-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-9304:
--
Attachment: 9304.patch
Block until no regions in transition and invoke the balancer like we do in the
0.94 version of this test.
> [0.92] TestDrainingServer fails occasionally
>
>
> Key: HBASE-9304
> URL: https://issues.apache.org/jira/browse/HBASE-9304
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Attachments: 9304.patch
>
>
> The error is the same in every case:
> {noformat}
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:48)
> at junit.framework.Assert.assertTrue(Assert.java:20)
> at junit.framework.Assert.assertFalse(Assert.java:34)
> at junit.framework.Assert.assertFalse(Assert.java:41)
> at
> org.apache.hadoop.hbase.TestDrainingServer.setUpBeforeClass(TestDrainingServer.java:78)
> {noformat}
> This is a check at test startup that every regionserver has an assignment.
> Looks like sometimes it takes a long time for the cluster to come up - there
> are 5 RSes started - and not all get region assignments. Probably a test only
> fix here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-9306) [0.92] TestAdmin.testCreateBadTables fails occasionally
[
https://issues.apache.org/jira/browse/HBASE-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell resolved HBASE-9306.
---
Resolution: Fixed
Fix Version/s: 0.92.3
> [0.92] TestAdmin.testCreateBadTables fails occasionally
> ---
>
> Key: HBASE-9306
> URL: https://issues.apache.org/jira/browse/HBASE-9306
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Fix For: 0.92.3
>
> Attachments: 9306.patch
>
>
> A typical failure:
> {noformat}
> java.lang.AssertionError: expected:<9> but was:<8>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.hadoop.hbase.client.TestAdmin.testCreateBadTables(TestAdmin.java:996)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9306) [0.92] TestAdmin.testCreateBadTables fails occasionally
[
https://issues.apache.org/jira/browse/HBASE-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell updated HBASE-9306:
--
Attachment: 9306.patch
Triage the concurrent part of TestAdmin.testCreateBadTables by commenting it
out.
> [0.92] TestAdmin.testCreateBadTables fails occasionally
> ---
>
> Key: HBASE-9306
> URL: https://issues.apache.org/jira/browse/HBASE-9306
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3
>Reporter: Andrew Purtell
>Assignee: Andrew Purtell
>Priority: Minor
> Attachments: 9306.patch
>
>
> A typical failure:
> {noformat}
> java.lang.AssertionError: expected:<9> but was:<8>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at
> org.apache.hadoop.hbase.client.TestAdmin.testCreateBadTables(TestAdmin.java:996)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9331) FuzzyRow filter getNextForFuzzyRule not working properly for special case
[
https://issues.apache.org/jira/browse/HBASE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749833#comment-13749833
]
Vasu Mariyala commented on HBASE-9331:
--
[~yuzhih...@gmail.com] Does FuzzyRowFilter have the below assumptions?
a) All the row keys are off the same length because the next for a valid fuzzy
row match (key={0,1,1,1}) can always be a zero appended byte array
(key={0,1,1,1,0}). If this assumption is always true, this jira could no longer
be an issue.
b) The length of the row key must always be greater than or equal to the length
of fuzzy row key or fuzzy info.
{code}
Assert.assertEquals(FuzzyRowFilter.SatisfiesCode.YES,
FuzzyRowFilter.satisfies(new byte[]{1, 0, 1}, // row to check only 3
bytes
new byte[]{1, 0, 1, 0, 1}, // fuzzy row
contains 5 bytes
new byte[]{0, 1, 0, 0, 0})); // mask contains
5 bytes
The intention is to extract the rows off the pattern 1?101. But a row 101
satisfies the pattern and is included in the results.
{code}
c) Does fuzzy row key need to have '0's even in the places where the fuzzy info
contains a 1 (indicates a non-fixed byte)
{code}
assertNext(
new byte[]{1, 1, 1, 1}, //fuzzy row
new byte[]{0, 0, 1, 1}, //fuzzy mask (info)
new byte[]{0, 1, 3, 2}, //current row
new byte[]{1, 1, 1, 1}); //next row (expected). FAILURE: There is a
potential match at {1,1,0,0} and has been ignored by the FuzzyRowFilter.
{code}
> FuzzyRow filter getNextForFuzzyRule not working properly for special case
> -
>
> Key: HBASE-9331
> URL: https://issues.apache.org/jira/browse/HBASE-9331
> Project: HBase
> Issue Type: Bug
> Components: Filters
>Affects Versions: 0.94.11
> Environment: Issue is not dependent upon environment.
>Reporter: Tony Dean
> Attachments: TestFuzzyRowFilter.patch
>
>
> The case that getNextForFuzzyRule() fails is when the result (fuzzy key) is
> extended in length (zero padded) to match the current row for comparisons.
> If the hint is returned with zero padded bytes, the next seek may skip over a
> valid match. See the example below.
> /**
> * The code below circumvents the following situation.
> *
> * fuzzy.key = visitor,session,Logon
> * fuzzy.mask = 11100
> *
> * example hbase row data:
> * visitor,session,AddToCart
> *" "FacebookLike
> *" "Logon
> *" "MobileSpecial
> *...
> *
> *
> * For row "visitor,sessionAddToCart", the current code would
> * return a hint of "visitor,session,Logon\0\0\0\0" (zero padded).
> * The next seek would skip "visitor,session,Logon" and jump
> * to "visitor,session,MobileSpecial".
> */
>
> // trim trailing zeros that were not part of the original fuzzy key
> int i = result.length;
> for (; i > fuzzyKeyBytes.length; i--)
> {
> if (result[i-1] != 0x00)
> break;
> }
> if (i != result.length)
> {
> result = Arrays.copyOf(result, i);
> }
> The code above added to the end of getNextFuzzyRule() will circumvent the
> issue. I tested my scenario and it produces the correct results. There may
> be a better solution.
> Thanks.
--
This message is automatically generated by JIRA.
If 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=13749829#comment-13749829 ] chunhui shen commented on HBASE-4811: - bq.Does the trunk patch do lazy seek? No. > 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-0.94-v3.txt, 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-trunkv17.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=13749822#comment-13749822
]
Hadoop QA commented on HBASE-4811:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599866/hbase-4811-trunkv17.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 18 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6894//console
This message is automatically generated.
> 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-0.94-v3.txt, 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-trunkv17.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=13749817#comment-13749817 ] Lars Hofhansl commented on HBASE-4811: -- Does the trunk patch do lazy seek? If not, let's do it in another issue as you suggest. > 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-0.94-v3.txt, 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-trunkv17.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-trunkv17.patch regenerating patch-v17 with protoc 2.5 > 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-0.94-v3.txt, 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-trunkv17.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=13749788#comment-13749788 ] chunhui shen commented on HBASE-4811: - [~lhofhansl] The patch for 0.94 version is quite old, should be re-made. Lazy seek is able to be applied in reversed scan. And have to change some methods from doing real seek to request seek. If necessary, I could make the new patch with lazy seek, else I prefer to take it as a new improvement issue > 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-0.94-v3.txt, 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-7709) Infinite loop possible in Master/Master replication
[ https://issues.apache.org/jira/browse/HBASE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasu Mariyala updated HBASE-7709: - Attachment: 0.95-trunk-rev4.patch Re-attaching the patch version 4 so that hadoop qa can run > Infinite loop possible in Master/Master replication > --- > > Key: HBASE-7709 > URL: https://issues.apache.org/jira/browse/HBASE-7709 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 0.94.6, 0.95.1 >Reporter: Lars Hofhansl >Assignee: Vasu Mariyala > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, > 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, > HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, > HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch > > > We just discovered the following scenario: > # Cluster A and B are setup in master/master replication > # By accident we had Cluster C replicate to Cluster A. > Now all edit originating from C will be bouncing between A and B. Forever! > The reason is that when the edit come in from C the cluster ID is already set > and won't be reset. > We have a couple of options here: > # Optionally only support master/master (not cycles of more than two > clusters). In that case we can always reset the cluster ID in the > ReplicationSource. That means that now cycles > 2 will have the data cycle > forever. This is the only option that requires no changes in the HLog format. > # Instead of a single cluster id per edit maintain a (unordered) set of > cluster id that have seen this edit. Then in ReplicationSource we drop any > edit that the sink has seen already. The is the cleanest approach, but it > might need a lot of data stored per edit if there are many clusters involved. > # Maintain a configurable counter of the maximum cycle side we want to > support. Could default to 10 (even maybe even just). Store a hop-count in the > WAL and the ReplicationSource increases that hop-count on each hop. If we're > over the max, just drop the edit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7709) Infinite loop possible in Master/Master replication
[ https://issues.apache.org/jira/browse/HBASE-7709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasu Mariyala updated HBASE-7709: - Attachment: (was: 0.95-trunk-rev4.patch) > Infinite loop possible in Master/Master replication > --- > > Key: HBASE-7709 > URL: https://issues.apache.org/jira/browse/HBASE-7709 > Project: HBase > Issue Type: Bug > Components: Replication >Affects Versions: 0.94.6, 0.95.1 >Reporter: Lars Hofhansl >Assignee: Vasu Mariyala > Fix For: 0.98.0, 0.94.12, 0.96.0 > > Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch, > 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch, > HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch, > HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch > > > We just discovered the following scenario: > # Cluster A and B are setup in master/master replication > # By accident we had Cluster C replicate to Cluster A. > Now all edit originating from C will be bouncing between A and B. Forever! > The reason is that when the edit come in from C the cluster ID is already set > and won't be reset. > We have a couple of options here: > # Optionally only support master/master (not cycles of more than two > clusters). In that case we can always reset the cluster ID in the > ReplicationSource. That means that now cycles > 2 will have the data cycle > forever. This is the only option that requires no changes in the HLog format. > # Instead of a single cluster id per edit maintain a (unordered) set of > cluster id that have seen this edit. Then in ReplicationSource we drop any > edit that the sink has seen already. The is the cleanest approach, but it > might need a lot of data stored per edit if there are many clusters involved. > # Maintain a configurable counter of the maximum cycle side we want to > support. Could default to 10 (even maybe even just). Store a hop-count in the > WAL and the ReplicationSource increases that hop-count on each hop. If we're > over the max, just drop the edit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9283) Struct and StructIterator should properly handle trailing nulls
[ https://issues.apache.org/jira/browse/HBASE-9283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated HBASE-9283: Attachment: 0001-HBASE-9283-Struct-trailing-null-handling.patch Hi [~giacomotaylor]. Have a look at this patch. TestStructNullExtension is designed to demonstrate the behavior we discussed. Notice I had to change all the nullable types. The difficulty is in determining whether the last entry is an implied null or something like an empty RawByte instance. The solution I have here is to require that any nullable type check for src.getPosition() == src.getLength() and return null instead of error out. Without this change, TestStruct fails precisely because of this discrepancy. > Struct and StructIterator should properly handle trailing nulls > --- > > Key: HBASE-9283 > URL: https://issues.apache.org/jira/browse/HBASE-9283 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.2 >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk > Fix For: 0.98.0, 0.96.0 > > Attachments: 0001-HBASE-9283-Struct-trailing-null-handling.patch > > > For a composite row key, Phoenix strips off trailing null columns values in > the row key. The reason this is important is that then new nullable row key > columns can be added to a schema without requiring any data upgrade to > existing rows. Otherwise, adding new row key columns to the end of a schema > becomes extremely cumbersome, as you'd need to delete all existing rows and > add them back with a row key that includes a null value. > Rather than Phoenix needing to modify the iteration code everywhere (as > [~ndimiduk] outlined here: > https://issues.apache.org/jira/browse/HBASE-8693?focusedCommentId=13744499&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13744499), > it'd be better if StructIterator handled this out-of-the-box. Otherwise, if > Phoenix has to specialize this, we'd lose the interop piece which is the > justification for switching our type system to this new one in the first > place. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9315) TestLruBlockCache.testBackgroundEvictionThread fails on suse
[
https://issues.apache.org/jira/browse/HBASE-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-9315:
Hadoop Flags: Reviewed
Status: Patch Available (was: Open)
> TestLruBlockCache.testBackgroundEvictionThread fails on suse
>
>
> Key: HBASE-9315
> URL: https://issues.apache.org/jira/browse/HBASE-9315
> Project: HBase
> Issue Type: Test
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Attachments:
> 0001-HBASE-9315-improve-test-stability-of-TestLruBlockCac.patch
>
>
> One of our build machines is consistently having trouble with this test.
> {noformat}
> Error Message
> expected:<2> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.hadoop.hbase.io.hfile.TestLruBlockCache.testBackgroundEvictionThread(TestLruBlockCache.java:85)
> 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:441)
> 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:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Standard Output
> Background Evictions run: 2
> Standard Error
> 2013-08-22 11:02:58,331 INFO [pool-1-thread-1] hbase.ResourceChecker(147):
> before: io.hfile.TestLruBlockCache#testBackgroundEvictionThread Thread=35,
> OpenFileDescriptor=277, MaxFileDescriptor=95000, SystemLoadAverage=119,
> ProcessCount=75, AvailableMemoryMB=8884, ConnectionCount=1
> 2013-08-22 11:02:58,338 INFO [pool-1-thread-1] hbase.ResourceChecker(171):
> after: io.hfile.TestLruBlockCache#testBackgroundEvictionThread Thread=36 (was
> 35) - Thread LEAK? -, OpenFileDescriptor=279 (was 277) - OpenFileDescriptor
> LEAK? -, MaxFileDescriptor=95000 (was 95000), SystemLoadAverage=119 (was
> 119), ProcessCount=75 (was 75), AvailableMemoryMB=8884 (was 8884),
> ConnectionCount=1 (was 1)
> 2013-08-22 11:07:58,331 DEBUG [LRU Statistics #0] hfile.LruBlockCache(728):
> Stats: total=87.01 KB, free=10.65 KB, max=97.66 KB, blocks=8, accesses=0,
> hits=0, hitRatio=0, cachingAccesses=0, cachingHits=0,
> cachingHitsRatio=0,evictions=2, evicted=2, evictedPerRun=1.0
> 2013-08-22 11:12:58,331 DEBUG [LRU Statistics #0] hfile.LruBlockCache(728):
> Stats: total=87.01 KB, free=10.65 KB, max=97.66 KB, blocks=8, accesses=0,
> hits=0, hitRatio=0, cachingAccesses=0, cachingHits=0,
> cachingHitsRatio=0,evictions=2, evicted=2, evictedPerRun=1.0
> 2013-08-22 11:17:58,331 DEBUG [LRU Statistics #0] hfile.LruBlockCache(728):
> Stats: total=87.01 KB, free=10.65 KB, max=97.66 KB, blocks=8, accesses=0,
> hits=0, hitRatio=0, cachingAccesses=0, cachingHits=0,
> cachingHitsRatio
[jira] [Updated] (HBASE-9315) TestLruBlockCache.testBackgroundEvictionThread fails on suse
[
https://issues.apache.org/jira/browse/HBASE-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk updated HBASE-9315:
Status: Open (was: Patch Available)
> TestLruBlockCache.testBackgroundEvictionThread fails on suse
>
>
> Key: HBASE-9315
> URL: https://issues.apache.org/jira/browse/HBASE-9315
> Project: HBase
> Issue Type: Test
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Attachments:
> 0001-HBASE-9315-improve-test-stability-of-TestLruBlockCac.patch
>
>
> One of our build machines is consistently having trouble with this test.
> {noformat}
> Error Message
> expected:<2> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.hadoop.hbase.io.hfile.TestLruBlockCache.testBackgroundEvictionThread(TestLruBlockCache.java:85)
> 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:441)
> 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:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Standard Output
> Background Evictions run: 2
> Standard Error
> 2013-08-22 11:02:58,331 INFO [pool-1-thread-1] hbase.ResourceChecker(147):
> before: io.hfile.TestLruBlockCache#testBackgroundEvictionThread Thread=35,
> OpenFileDescriptor=277, MaxFileDescriptor=95000, SystemLoadAverage=119,
> ProcessCount=75, AvailableMemoryMB=8884, ConnectionCount=1
> 2013-08-22 11:02:58,338 INFO [pool-1-thread-1] hbase.ResourceChecker(171):
> after: io.hfile.TestLruBlockCache#testBackgroundEvictionThread Thread=36 (was
> 35) - Thread LEAK? -, OpenFileDescriptor=279 (was 277) - OpenFileDescriptor
> LEAK? -, MaxFileDescriptor=95000 (was 95000), SystemLoadAverage=119 (was
> 119), ProcessCount=75 (was 75), AvailableMemoryMB=8884 (was 8884),
> ConnectionCount=1 (was 1)
> 2013-08-22 11:07:58,331 DEBUG [LRU Statistics #0] hfile.LruBlockCache(728):
> Stats: total=87.01 KB, free=10.65 KB, max=97.66 KB, blocks=8, accesses=0,
> hits=0, hitRatio=0, cachingAccesses=0, cachingHits=0,
> cachingHitsRatio=0,evictions=2, evicted=2, evictedPerRun=1.0
> 2013-08-22 11:12:58,331 DEBUG [LRU Statistics #0] hfile.LruBlockCache(728):
> Stats: total=87.01 KB, free=10.65 KB, max=97.66 KB, blocks=8, accesses=0,
> hits=0, hitRatio=0, cachingAccesses=0, cachingHits=0,
> cachingHitsRatio=0,evictions=2, evicted=2, evictedPerRun=1.0
> 2013-08-22 11:17:58,331 DEBUG [LRU Statistics #0] hfile.LruBlockCache(728):
> Stats: total=87.01 KB, free=10.65 KB, max=97.66 KB, blocks=8, accesses=0,
> hits=0, hitRatio=0, cachingAccesses=0, cachingHits=0,
> cachingHitsRatio=0,evictions=2, evicted=2, evicte
[jira] [Commented] (HBASE-9328) Table web UI is corrupted sometime
[
https://issues.apache.org/jira/browse/HBASE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749723#comment-13749723
]
Hadoop QA commented on HBASE-9328:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599834/HBASE-9328-v2-trunk.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 hadoop1.0{color}. The patch failed to compile against the
hadoop 1.0 profile.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6893//console
This message is automatically generated.
> Table web UI is corrupted sometime
> --
>
> Key: HBASE-9328
> URL: https://issues.apache.org/jira/browse/HBASE-9328
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 0.95.2, 0.94.11
>Reporter: Jimmy Xiang
>Assignee: Jean-Marc Spaggiari
> Labels: web-ui
> Attachments: HBASE-9328-v0-trunk.patch, HBASE-9328-v1-trunk.patch,
> HBASE-9328-v2-0.94.patch, HBASE-9328-v2-trunk.patch, table.png
>
>
> The web UI page source is like below:
> {noformat}
> Table Attributes
>
>
> Attribute Name
> Value
> Description
>
>
> Enabled
> true
> Is the table enabled
>
>
> Compaction
>
>
> {noformat}
> No sure if it is a HBase issue, or a network/browser issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9281) user_permission command encounters NullPointerException
[
https://issues.apache.org/jira/browse/HBASE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749722#comment-13749722
]
Hadoop QA commented on HBASE-9281:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599064/9281-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:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6892//console
This message is automatically generated.
> user_permission command encounters NullPointerException
> ---
>
> Key: HBASE-9281
> URL: https://issues.apache.org/jira/browse/HBASE-9281
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 9281-v1.txt
>
>
> As user hbase, user_permission command gave:
> {code}
> java.io.IOException: java.io.IOException
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
> at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
> Caused by: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePermissions(AccessControlLists.java:484)
> at
> org.apache.hadoop.hbase.security.access.AccessController.getUserPermissions(AccessController.java:1341)
> at
> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$1.getUserPermissions(AccessControlProtos.java:9949)
> at
> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService.callMethod(AccessControlProtos.java:10107)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:5121)
> at
> org.apache.hadoop.hbase.regionserver.HRegionServer.execService(HRegionServer.java:3211)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:26851)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2147)
> ... 1 more
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95)
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getRemoteException(ProtobufUtil.java:235)
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.execService(ProtobufUtil.java:1304)
> at
> org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:87)
> at
> org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel$1.call(RegionCoprocessorRpcChannel.java:84)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:120)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:98)
> at
> org.apache.hadoop.hbase.ipc.RegionCoprocessorRpcChannel.callExecService(RegionCoprocessorRpcChannel.java:90)
> at
> org.apache.hadoop.hbase.ipc.CoprocessorRpcChannel.callBlockingMethod(CoprocessorRpcChannel.java:67)
> at
> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos$AccessControlService$BlockingStub.getUserPermissions(AccessControlProtos.java:10304)
> at
> org.apache.hadoop.hbase.protobuf.ProtobufUtil.getUserPermissions(ProtobufUtil.java:1974)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> ...
> Caused by:
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(java.io.IOException):
> java.io.IOException
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2185)
> at org.apache.hadoop.hbase.ipc.RpcServer$Handler.run(RpcServer.java:1854)
> Caused by: java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.security.access.AccessControlLists.getUserTablePer
[jira] [Commented] (HBASE-8960) TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
[
https://issues.apache.org/jira/browse/HBASE-8960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749721#comment-13749721
]
Hadoop QA commented on HBASE-8960:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599303/hbase-8960-fix-disallowWritesInRecovering-addendum.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/6891//console
This message is automatically generated.
> TestDistributedLogSplitting.testLogReplayForDisablingTable fails sometimes
> --
>
> Key: HBASE-8960
> URL: https://issues.apache.org/jira/browse/HBASE-8960
> Project: HBase
> Issue Type: Task
> Components: test
>Reporter: Jimmy Xiang
>Assignee: Jeffrey Zhong
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: hbase-8690-v4.patch, hbase-8960-addendum-2.patch,
> hbase-8960-addendum.patch,
> hbase-8960-fix-disallowWritesInRecovering-addendum.patch,
> hbase-8960-fix-disallowWritesInRecovering.patch, hbase-8960.patch
>
>
> http://54.241.6.143/job/HBase-0.95-Hadoop-2/org.apache.hbase$hbase-server/634/testReport/junit/org.apache.hadoop.hbase.master/TestDistributedLogSplitting/testLogReplayForDisablingTable/
> {noformat}
> java.lang.AssertionError: expected:<1000> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.hadoop.hbase.master.TestDistributedLogSplitting.testLogReplayForDisablingTable(TestDistributedLogSplitting.java:797)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.FailOnTimeout$StatementThread.run(FailOnTimeout.java:74)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9241) Add cp hook before initialize variable set to true in master intialization
[
https://issues.apache.org/jira/browse/HBASE-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749717#comment-13749717
]
Hadoop QA commented on HBASE-9241:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599408/HBASE-9241_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 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:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.mapreduce.TestHFileOutputFormat
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6890//console
This message is automatically generated.
> 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
>Assignee: rajeshbabu
> Attachments: HBASE-9241_2.patch, HBASE-9241.patch
>
>
> 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] [Commented] (HBASE-8462) Custom timestamps should not be allowed to be negative
[
https://issues.apache.org/jira/browse/HBASE-8462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749719#comment-13749719
]
Hadoop QA commented on HBASE-8462:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599204/hbase-8462_v3.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 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestFullLogReconstruction
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6889//console
This message is automatically generated.
> Custom timestamps should not be allowed to be negative
> --
>
> Key: HBASE-8462
> URL: https://issues.apache.org/jira/browse/HBASE-8462
> Project: HBase
> Issue Type: Bug
> Components: Client
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 0.98.0, 0.96.0
>
> Attachments: hbase-8462_v1.patch, hbase-8462_v2.patch,
> hbase-8462_v3.patch
>
>
> Client supplied timestamps should not be allowed to be negative, otherwise
> unpredictable results will follow. Especially, since we are encoding the ts
> using Bytes.Bytes(long), negative timestamps are sorted after positive ones.
> Plus, the new PB messages define ts' as uint64.
> Credit goes to Huned Lokhandwala for reporting this.
--
This message is automatically generated by JIRA.
If 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=13749710#comment-13749710
]
Hadoop QA commented on HBASE-8348:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599519/8348v5.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 7 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/6888//console
This message is automatically generated.
> 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: Blocker
> Fix For: 0.96.0
>
> Attachments: 8348v5.txt, 8348v5.txt, HBASE-8348-approach-2.patch,
> HBASE-8348-approach-2-v2.1.patch, HBASE-8348-approach-2-v2.2.patch,
> HBASE-8348-approach-2-v2.3.patch, HBASE-8348-approach-2-v2.4.patch,
> HBASE-8348-approach-3.patch, HBASE-8348_trunk.patch,
> HBASE-8348_trunk_v2.patch, HBASE-8348_trunk_v3.patch, log, log-2
>
>
> 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-9302) Column family and qualifier should be allowed to be set as null in grant shell command
[
https://issues.apache.org/jira/browse/HBASE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749709#comment-13749709
]
Hadoop QA commented on HBASE-9302:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599463/9302.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:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6887//console
This message is automatically generated.
> Column family and qualifier should be allowed to be set as null in grant
> shell command
> --
>
> Key: HBASE-9302
> URL: https://issues.apache.org/jira/browse/HBASE-9302
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.92.3, 0.98.0, 0.96.0
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 9302.txt
>
>
> In 0.94, grant.rb has the following:
> {code}
> Grant users specific rights.
> Syntax : grant [ [ [ qualifier>]]
> {code}
> In 0.95.2, when I tried to grant permission on a table to user hrt_1, I got
> some exception:
> {code}
> hbase(main):003:0> grant 'hrt_1', 'R', 't1'
> ERROR: java.lang.NullPointerException: null
> Here is some help for this command:
> Grant users specific rights.
> Syntax : grant
> permissions is either zero or more letters from the set "RWXCA".
> READ('R'), WRITE('W'), EXEC('X'), CREATE('C'), ADMIN('A')
> For example:
> hbase> grant 'bobsmith', 'RWXCA'
> hbase> grant 'bobsmith', 'RW', 't1', 'f1', 'col1'
> {code}
> Column family and qualifier should be allowed to be set as null in grant
> shell command
--
This message is automatically generated by JIRA.
If 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-9247) Cleanup Key/KV/Meta/MetaKey Comparators
[
https://issues.apache.org/jira/browse/HBASE-9247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749708#comment-13749708
]
Hadoop QA commented on HBASE-9247:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599594/hbase-9247.v2.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 39 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6886//console
This message is automatically generated.
> Cleanup Key/KV/Meta/MetaKey Comparators
> ---
>
> Key: HBASE-9247
> URL: https://issues.apache.org/jira/browse/HBASE-9247
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 0.95.2
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-9247.patch, hbase-9247.v2.patch
>
>
> 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] [Commented] (HBASE-7462) TestDrainingServer is an integration test. It should be a unit test instead
[
https://issues.apache.org/jira/browse/HBASE-7462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749705#comment-13749705
]
Hadoop QA commented on HBASE-7462:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12598658/HBASE-7462-v2.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:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6885//console
This message is automatically generated.
> TestDrainingServer is an integration test. It should be a unit test instead
> ---
>
> Key: HBASE-7462
> URL: https://issues.apache.org/jira/browse/HBASE-7462
> Project: HBase
> Issue Type: Wish
> Components: test
>Affects Versions: 0.95.2
>Reporter: Nicolas Liochon
>Assignee: Gustavo Anatoly
>Priority: Trivial
> Labels: noob
> Attachments: HBASE-7462-v2.patch
>
>
> TestDrainingServer tests the function that allows to say that a regionserver
> should not get new regions.
> As it is written today, it's an integration test: it starts & stops a cluster.
> The test would be more efficient if it would just check that the
> AssignmentManager does not use the drained region server; whatever the
> circumstances (bulk assign or not for example).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9315) TestLruBlockCache.testBackgroundEvictionThread fails on suse
[
https://issues.apache.org/jira/browse/HBASE-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749683#comment-13749683
]
Hadoop QA commented on HBASE-9315:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599549/0001-HBASE-9315-improve-test-stability-of-TestLruBlockCac.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6883//console
This message is automatically generated.
> TestLruBlockCache.testBackgroundEvictionThread fails on suse
>
>
> Key: HBASE-9315
> URL: https://issues.apache.org/jira/browse/HBASE-9315
> Project: HBase
> Issue Type: Test
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Attachments:
> 0001-HBASE-9315-improve-test-stability-of-TestLruBlockCac.patch
>
>
> One of our build machines is consistently having trouble with this test.
> {noformat}
> Error Message
> expected:<2> but was:<1>
> Stacktrace
> java.lang.AssertionError: expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at
> org.apache.hadoop.hbase.io.hfile.TestLruBlockCache.testBackgroundEvictionThread(TestLruBlockCache.java:85)
> 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
[jira] [Commented] (HBASE-9286) ageOfLastShippedOp replication metric doesn't update if the slave regionserver is stalled
[
https://issues.apache.org/jira/browse/HBASE-9286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749684#comment-13749684
]
Hadoop QA commented on HBASE-9286:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599106/0001-HBASE-9286.-ageOfLastShippedOp-replication-metric-do.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/6884//console
This message is automatically generated.
> ageOfLastShippedOp replication metric doesn't update if the slave
> regionserver is stalled
> -
>
> Key: HBASE-9286
> URL: https://issues.apache.org/jira/browse/HBASE-9286
> Project: HBase
> Issue Type: Bug
>Reporter: Alex Newman
>Assignee: Alex Newman
> Attachments:
> 0001-HBASE-9286.-ageOfLastShippedOp-replication-metric-do.patch
>
>
> In replicationmanager
> HRegionInterface rrs = getRS();
> rrs.replicateLogEntries(Arrays.copyOf(this.entriesArray,
> currentNbEntries));
>
> this.metrics.setAgeOfLastShippedOp(
> this.entriesArray[currentNbEntries-1].getKey().getWriteTime());
> break;
> which makes sense, but is wrong. The problem is that rrs.replicateLogEntries
> will block for a very long time if the slave server is suspended or
> unavailable but not down.
> However this is easy to fix. We just need to call
> refreshAgeOfLastShippedOp();
> on a regular basis, in a different thread. I've attached a patch which fixed
> this for cdh4. I can make one for trunk and the like as well if you need me
> to do but it's a small change.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9307) HalfStoreFileReader needs to handle the faked key else compactions go into infinite loops
[
https://issues.apache.org/jira/browse/HBASE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749681#comment-13749681
]
Hadoop QA commented on HBASE-9307:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599490/HBASE-9307.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6882//console
This message is automatically generated.
> HalfStoreFileReader needs to handle the faked key else compactions go into
> infinite loops
> -
>
> Key: HBASE-9307
> URL: https://issues.apache.org/jira/browse/HBASE-9307
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Jean-Daniel Cryans
>Assignee: Jean-Daniel Cryans
>Priority: Critical
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9307.patch
>
>
> I found this while trying out 0.95.2
> I couldn't shut my cluster down because one region was still compacting, but
> it already had been doing that for an hour and it only had 80MBs of data.
> Debugging I saw that it was a post-split compaction, specifically for the top
> part of the HFiles, and that it was just spinning on the first entry in the
> file.
> Eventually I saw that the anonymous HFileScanner inside
> HalfStoreFileReader.getScanner (that's so dirty) wasn't handling
> HConstants.INDEX_KEY_MAGIC in seekTo() when calling this:
> bq. this.delegate.seekTo(splitkey)
> Instead it would treat this as if the split key wasn't in the file, but still
> seek back to the beginning of the file *then read on from there*.
> During the compaction it would see a KV that's not even part of the region,
> and it just tries to find the correct block over and over again.
> This came from HBASE-7845.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9249) Add cp hook before setting PONR in split
[
https://issues.apache.org/jira/browse/HBASE-9249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749666#comment-13749666
]
Hadoop QA commented on HBASE-9249:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599371/HBASE-9249_v2.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: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:red}-1 findbugs{color}. The patch appears to introduce 2 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6880//console
This message is automatically generated.
> Add cp hook before setting PONR in split
>
>
> Key: HBASE-9249
> URL: https://issues.apache.org/jira/browse/HBASE-9249
> Project: HBase
> Issue Type: Sub-task
>Reporter: rajeshbabu
>Assignee: rajeshbabu
> Attachments: HBASE-9249.patch, HBASE-9249_v2.patch
>
>
> This hook helps to perform split on user region and corresponding index
> region such that both will be split or none.
> With this hook split for user and index region as follows
> user region
> ===
> 1) Create splitting znode for user region split
> 2) Close parent user region
> 3) split user region storefiles
> 4) instantiate child regions of user region
> Through the new hook we can call index region transitions as below
> index region
> ===
> 5) Create splitting znode for index region split
> 6) Close parent index region
> 7) Split storefiles of index region
> 8) instantiate child regions of the index region
> If any failures in 5,6,7,8 rollback the steps and return null, on null return
> throw exception to rollback for 1,2,3,4
> 9) set PONR
> 10) do batch put of offline and split entries for user and index regions
> index region
>
> 11) open daughers of index regions and transition znode to split. This step
> we will do through preSplitAfterPONR hook. Opening index regions before
> opening user regions helps to avoid put failures if there is colocation
> mismatch(this can happen if user regions opening completed but index regions
> opening in progress)
> user region
> ===
> 12) open daughers of user regions and transition znode to split.
> Even if region server crashes also at the end both user and index regions
> will be split or none
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact
[jira] [Commented] (HBASE-9261) Add cp hooks after {start|close}RegionOperation in batchMutate
[
https://issues.apache.org/jira/browse/HBASE-9261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749665#comment-13749665
]
Hadoop QA commented on HBASE-9261:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599135/HBASE-9261.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 6 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 3
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6881//console
This message is automatically generated.
> Add cp hooks after {start|close}RegionOperation in batchMutate
> --
>
> Key: HBASE-9261
> URL: https://issues.apache.org/jira/browse/HBASE-9261
> Project: HBase
> Issue Type: Sub-task
>Reporter: rajeshbabu
>Assignee: rajeshbabu
> Attachments: HBASE-9261.patch
>
>
> These hooks helps for checking Resources(blocking memstore size) and
> necessary locking on index region while performing batch of mutations.
--
This message is automatically generated by JIRA.
If 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-9335) Zombie test detection should filter out non-HBase tests
[
https://issues.apache.org/jira/browse/HBASE-9335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749662#comment-13749662
]
Nicolas Liochon commented on HBASE-9335:
I don't think we should.
We're supposed to be alone. If there is another test running in parallel, it's
strange and it's worth knowing, as it can take some resources we need / expect.
> Zombie test detection should filter out non-HBase tests
> ---
>
> Key: HBASE-9335
> URL: https://issues.apache.org/jira/browse/HBASE-9335
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>
> Zombie test detection in test-patch.sh sometimes picks up tests from other
> TLP.
> e.g. from https://builds.apache.org/job/PreCommit-HBASE-Build/6869/console:
> {code}
> "main" prio=10 tid=0x091b4800 nid=0x7634 waiting on condition [0xf69b1000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.hadoop.hdfs.server.namenode.ha.TestFailoverWithBlockTokensEnabled.TestFailoverAfterAccessKeyUpdate(TestFailoverWithBlockTokensEnabled.java:159)
> {code}
> When the zombie test doesn't belong to org.apache.hadoop.hbase namespace, it
> shouldn't be listed.
--
This message is automatically generated by JIRA.
If 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-9335) Zombie test detection should filter out non-HBase tests
[
https://issues.apache.org/jira/browse/HBASE-9335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749651#comment-13749651
]
Ted Yu commented on HBASE-9335:
---
In the above QA run all tests passed:
{code}
[INFO] HBase . SUCCESS [2.159s]
[INFO] HBase - Common SUCCESS [19.357s]
[INFO] HBase - Protocol .. SUCCESS [16.276s]
[INFO] HBase - Client SUCCESS [19.758s]
[INFO] HBase - Hadoop Compatibility .. SUCCESS [5.151s]
[INFO] HBase - Hadoop One Compatibility .. SUCCESS [1.052s]
[INFO] HBase - Prefix Tree ... SUCCESS [3.252s]
[INFO] HBase - Server SUCCESS [54:46.750s]
[INFO] HBase - Integration Tests . SUCCESS [1.476s]
[INFO] HBase - Examples .. SUCCESS [6.064s]
[INFO] HBase - Assembly .. SUCCESS [0.877s]
{code}
A simple solution is to detect the completion of Assembly module and skip
zombie test detection step.
> Zombie test detection should filter out non-HBase tests
> ---
>
> Key: HBASE-9335
> URL: https://issues.apache.org/jira/browse/HBASE-9335
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>
> Zombie test detection in test-patch.sh sometimes picks up tests from other
> TLP.
> e.g. from https://builds.apache.org/job/PreCommit-HBASE-Build/6869/console:
> {code}
> "main" prio=10 tid=0x091b4800 nid=0x7634 waiting on condition [0xf69b1000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.hadoop.hdfs.server.namenode.ha.TestFailoverWithBlockTokensEnabled.TestFailoverAfterAccessKeyUpdate(TestFailoverWithBlockTokensEnabled.java:159)
> {code}
> When the zombie test doesn't belong to org.apache.hadoop.hbase namespace, it
> shouldn't be listed.
--
This message is automatically generated by JIRA.
If 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-9336) Two css files raise release audit warning
Ted Yu created HBASE-9336:
-
Summary: Two css files raise release audit warning
Key: HBASE-9336
URL: https://issues.apache.org/jira/browse/HBASE-9336
Project: HBase
Issue Type: Task
Reporter: Ted Yu
>From
>https://builds.apache.org/job/PreCommit-HBASE-Build/6869/artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
> :
{code}
!?
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.css
!?
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/trunk/hbase-server/src/main/resources/hbase-webapps/static/css/bootstrap-theme.min.css
Lines that start with ? in the release audit report indicate files that do
not have an Apache license header.
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9317) Define timeout period for TestHBaseFsck#testSplitDaughtersNotInMeta
[
https://issues.apache.org/jira/browse/HBASE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749649#comment-13749649
]
Ted Yu commented on HBASE-9317:
---
{code}
Running org.apache.hadoop.hbase.util.TestHBaseFsck
Tests run: 37, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 223.988 sec
...
[INFO] HBase . SUCCESS [2.159s]
[INFO] HBase - Common SUCCESS [19.357s]
[INFO] HBase - Protocol .. SUCCESS [16.276s]
[INFO] HBase - Client SUCCESS [19.758s]
[INFO] HBase - Hadoop Compatibility .. SUCCESS [5.151s]
[INFO] HBase - Hadoop One Compatibility .. SUCCESS [1.052s]
[INFO] HBase - Prefix Tree ... SUCCESS [3.252s]
[INFO] HBase - Server SUCCESS [54:46.750s]
[INFO] HBase - Integration Tests . SUCCESS [1.476s]
[INFO] HBase - Examples .. SUCCESS [6.064s]
[INFO] HBase - Assembly .. SUCCESS [0.877s]
{code}
Zombie test detection needs to be enhanced.
> Define timeout period for TestHBaseFsck#testSplitDaughtersNotInMeta
> ---
>
> Key: HBASE-9317
> URL: https://issues.apache.org/jira/browse/HBASE-9317
> Project: HBase
> Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 9317-v1.txt, 9317-v2.txt
>
>
> In hbase-0.95-on-hadoop2 build #247, TestHBaseFsck hung in
> testSplitDaughtersNotInMeta.
> This sub-task defines timeout period for
> TestHBaseFsck#testSplitDaughtersNotInMeta so that long running test would be
> timed out instead of hanging.
--
This message is automatically generated by JIRA.
If 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-9335) Zombie test detection should filter out non-HBase tests
Ted Yu created HBASE-9335:
-
Summary: Zombie test detection should filter out non-HBase tests
Key: HBASE-9335
URL: https://issues.apache.org/jira/browse/HBASE-9335
Project: HBase
Issue Type: Test
Reporter: Ted Yu
Zombie test detection in test-patch.sh sometimes picks up tests from other TLP.
e.g. from https://builds.apache.org/job/PreCommit-HBASE-Build/6869/console:
{code}
"main" prio=10 tid=0x091b4800 nid=0x7634 waiting on condition [0xf69b1000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at
org.apache.hadoop.hdfs.server.namenode.ha.TestFailoverWithBlockTokensEnabled.TestFailoverAfterAccessKeyUpdate(TestFailoverWithBlockTokensEnabled.java:159)
{code}
When the zombie test doesn't belong to org.apache.hadoop.hbase namespace, it
shouldn't be listed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9329) SnapshotManager should check for directory existance before throwing a warning.
[
https://issues.apache.org/jira/browse/HBASE-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749648#comment-13749648
]
Matteo Bertozzi commented on HBASE-9329:
+1 for me, no need to attach a 94 version since the code is exactly the same.
I'll commit it tomorrow in 0.94/0.95/trunk for no other comments.
> SnapshotManager should check for directory existance before throwing a
> warning.
> ---
>
> Key: HBASE-9329
> URL: https://issues.apache.org/jira/browse/HBASE-9329
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 0.98.0, 0.95.2, 0.94.11
>Reporter: Jean-Marc Spaggiari
>Assignee: Jean-Marc Spaggiari
>Priority: Trivial
> Attachments: HBASE-9329-v0-trunk.patch
>
>
> {quote}
> 2013-08-23 17:57:24,277 WARN
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete
> working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
> {quote}
> I don't have any .hbase-snapshot directory, so there is no need to try to
> delete the .tmp directory into it. Might first need to check if this
> directory exist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9329) SnapshotManager should check for directory existance before throwing a warning.
[
https://issues.apache.org/jira/browse/HBASE-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-9329:
---
Status: Open (was: Patch Available)
> SnapshotManager should check for directory existance before throwing a
> warning.
> ---
>
> Key: HBASE-9329
> URL: https://issues.apache.org/jira/browse/HBASE-9329
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 0.94.11, 0.95.2, 0.98.0
>Reporter: Jean-Marc Spaggiari
>Assignee: Jean-Marc Spaggiari
>Priority: Trivial
> Attachments: HBASE-9329-v0-trunk.patch
>
>
> {quote}
> 2013-08-23 17:57:24,277 WARN
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete
> working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
> {quote}
> I don't have any .hbase-snapshot directory, so there is no need to try to
> delete the .tmp directory into it. Might first need to check if this
> directory exist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9329) SnapshotManager should check for directory existance before throwing a warning.
[
https://issues.apache.org/jira/browse/HBASE-9329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-9329:
---
Status: Patch Available (was: Open)
> SnapshotManager should check for directory existance before throwing a
> warning.
> ---
>
> Key: HBASE-9329
> URL: https://issues.apache.org/jira/browse/HBASE-9329
> Project: HBase
> Issue Type: Bug
> Components: snapshots
>Affects Versions: 0.94.11, 0.95.2, 0.98.0
>Reporter: Jean-Marc Spaggiari
>Assignee: Jean-Marc Spaggiari
>Priority: Trivial
> Attachments: HBASE-9329-v0-trunk.patch
>
>
> {quote}
> 2013-08-23 17:57:24,277 WARN
> org.apache.hadoop.hbase.master.snapshot.SnapshotManager: Couldn't delete
> working snapshot directory: hdfs://node3:9000/hbase/.hbase-snapshot/.tmp
> {quote}
> I don't have any .hbase-snapshot directory, so there is no need to try to
> delete the .tmp directory into it. Might first need to check if this
> directory exist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-9328) Table web UI is corrupted sometime
[
https://issues.apache.org/jira/browse/HBASE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Spaggiari updated HBASE-9328:
---
Status: Patch Available (was: Open)
> Table web UI is corrupted sometime
> --
>
> Key: HBASE-9328
> URL: https://issues.apache.org/jira/browse/HBASE-9328
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.11, 0.95.2, 0.98.0
>Reporter: Jimmy Xiang
>Assignee: Jean-Marc Spaggiari
> Labels: web-ui
> Attachments: HBASE-9328-v0-trunk.patch, HBASE-9328-v1-trunk.patch,
> HBASE-9328-v2-0.94.patch, HBASE-9328-v2-trunk.patch, table.png
>
>
> The web UI page source is like below:
> {noformat}
> Table Attributes
>
>
> Attribute Name
> Value
> Description
>
>
> Enabled
> true
> Is the table enabled
>
>
> Compaction
>
>
> {noformat}
> No sure if it is a HBase issue, or a network/browser issue.
--
This message is automatically generated by JIRA.
If 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-9328) Table web UI is corrupted sometime
[
https://issues.apache.org/jira/browse/HBASE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Spaggiari updated HBASE-9328:
---
Attachment: HBASE-9328-v2-trunk.patch
Trunk version attached.
> Table web UI is corrupted sometime
> --
>
> Key: HBASE-9328
> URL: https://issues.apache.org/jira/browse/HBASE-9328
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 0.95.2, 0.94.11
>Reporter: Jimmy Xiang
>Assignee: Jean-Marc Spaggiari
> Labels: web-ui
> Attachments: HBASE-9328-v0-trunk.patch, HBASE-9328-v1-trunk.patch,
> HBASE-9328-v2-0.94.patch, HBASE-9328-v2-trunk.patch, table.png
>
>
> The web UI page source is like below:
> {noformat}
> Table Attributes
>
>
> Attribute Name
> Value
> Description
>
>
> Enabled
> true
> Is the table enabled
>
>
> Compaction
>
>
> {noformat}
> No sure if it is a HBase issue, or a network/browser issue.
--
This message is automatically generated by JIRA.
If 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-9328) Table web UI is corrupted sometime
[
https://issues.apache.org/jira/browse/HBASE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Spaggiari updated HBASE-9328:
---
Attachment: HBASE-9328-v2-0.94.patch
Sorry, wrong version. Was for 0.94 and not for trunk. 0.94 attached again for
naming convention.
> Table web UI is corrupted sometime
> --
>
> Key: HBASE-9328
> URL: https://issues.apache.org/jira/browse/HBASE-9328
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 0.95.2, 0.94.11
>Reporter: Jimmy Xiang
>Assignee: Jean-Marc Spaggiari
> Labels: web-ui
> Attachments: HBASE-9328-v0-trunk.patch, HBASE-9328-v1-trunk.patch,
> HBASE-9328-v2-0.94.patch, table.png
>
>
> The web UI page source is like below:
> {noformat}
> Table Attributes
>
>
> Attribute Name
> Value
> Description
>
>
> Enabled
> true
> Is the table enabled
>
>
> Compaction
>
>
> {noformat}
> No sure if it is a HBase issue, or a network/browser issue.
--
This message is automatically generated by JIRA.
If 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-9328) Table web UI is corrupted sometime
[
https://issues.apache.org/jira/browse/HBASE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Marc Spaggiari updated HBASE-9328:
---
Status: Open (was: Patch Available)
> Table web UI is corrupted sometime
> --
>
> Key: HBASE-9328
> URL: https://issues.apache.org/jira/browse/HBASE-9328
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.11, 0.95.2, 0.98.0
>Reporter: Jimmy Xiang
>Assignee: Jean-Marc Spaggiari
> Labels: web-ui
> Attachments: HBASE-9328-v0-trunk.patch, HBASE-9328-v1-trunk.patch,
> HBASE-9328-v2-0.94.patch, table.png
>
>
> The web UI page source is like below:
> {noformat}
> Table Attributes
>
>
> Attribute Name
> Value
> Description
>
>
> Enabled
> true
> Is the table enabled
>
>
> Compaction
>
>
> {noformat}
> No sure if it is a HBase issue, or a network/browser issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9307) HalfStoreFileReader needs to handle the faked key else compactions go into infinite loops
[ https://issues.apache.org/jira/browse/HBASE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749633#comment-13749633 ] Liang Xie commented on HBASE-9307: -- i still could not find why it never happened in our clusters in the past so far. let me try to make a test case for it and manage to do a deeper debug. > HalfStoreFileReader needs to handle the faked key else compactions go into > infinite loops > - > > Key: HBASE-9307 > URL: https://issues.apache.org/jira/browse/HBASE-9307 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.2 >Reporter: Jean-Daniel Cryans >Assignee: Jean-Daniel Cryans >Priority: Critical > Fix For: 0.98.0, 0.96.0 > > Attachments: HBASE-9307.patch > > > I found this while trying out 0.95.2 > I couldn't shut my cluster down because one region was still compacting, but > it already had been doing that for an hour and it only had 80MBs of data. > Debugging I saw that it was a post-split compaction, specifically for the top > part of the HFiles, and that it was just spinning on the first entry in the > file. > Eventually I saw that the anonymous HFileScanner inside > HalfStoreFileReader.getScanner (that's so dirty) wasn't handling > HConstants.INDEX_KEY_MAGIC in seekTo() when calling this: > bq. this.delegate.seekTo(splitkey) > Instead it would treat this as if the split key wasn't in the file, but still > seek back to the beginning of the file *then read on from there*. > During the compaction it would see a KV that's not even part of the region, > and it just tries to find the correct block over and over again. > This came from HBASE-7845. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9330) Refactor PE to create HTable the correct way
[
https://issues.apache.org/jira/browse/HBASE-9330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749626#comment-13749626
]
Hadoop QA commented on HBASE-9330:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599737/HBASE-9330.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:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.TestFullLogReconstruction
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6876//console
This message is automatically generated.
> Refactor PE to create HTable the correct way
>
>
> Key: HBASE-9330
> URL: https://issues.apache.org/jira/browse/HBASE-9330
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.95.2
>Reporter: Jean-Daniel Cryans
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBASE-9330.patch
>
>
> Multithreaded clients that directly create HTables are out of style and will
> be crushed under thousands of threads. Our own PerformanceEvaluation is now
> suffering from this too, so it needs to keep an HConnection around in order
> to create tables.
--
This message is automatically generated by JIRA.
If 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-9153) Create a deprecation policy enforcement check
[
https://issues.apache.org/jira/browse/HBASE-9153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749624#comment-13749624
]
Hadoop QA commented on HBASE-9153:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599735/HBASE-9153-v1.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:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.thrift.TestThriftServer
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6877//console
This message is automatically generated.
> Create a deprecation policy enforcement check
> -
>
> Key: HBASE-9153
> URL: https://issues.apache.org/jira/browse/HBASE-9153
> Project: HBase
> Issue Type: Task
>Reporter: Jonathan Hsieh
> Attachments: HBASE-9153-v1.patch
>
>
> We've had a few issues now where we've removed API's without deprecating or
> deprecating in the late release. (HBASE-9142, HBASE-9093) We should just
> have a tool that enforces our api deprecation policy as a release time check
> or as a precommit check.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9278) Reading Pre-namespace meta table edits kills the reader
[
https://issues.apache.org/jira/browse/HBASE-9278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749613#comment-13749613
]
Hadoop QA commented on HBASE-9278:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599749/HBase-9278-v0.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6875//console
This message is automatically generated.
> Reading Pre-namespace meta table edits kills the reader
> ---
>
> Key: HBASE-9278
> URL: https://issues.apache.org/jira/browse/HBASE-9278
> Project: HBase
> Issue Type: Bug
> Components: migration, wal
>Affects Versions: 0.95.2
>Reporter: Himanshu Vashishtha
>Assignee: Himanshu Vashishtha
>Priority: Critical
> Fix For: 0.98.0, 0.96.0
>
> Attachments: HBase-9278-v0.patch
>
>
> In upgrading to 0.96, there might be some meta/root table edits. Currently,
> we are just killing SplitLogWorker thread in case it sees any META, or ROOT
> waledit, which blocks log splitting/replaying of remaining WALs.
> {code}
> 2013-08-20 15:45:16,998 ERROR regionserver.SplitLogWorker
> (SplitLogWorker.java:run(210)) - unexpected error
> java.lang.IllegalArgumentException: .META. no longer exists. The table has
> been renamed to hbase:meta
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:269)
> at org.apache.hadoop.hbase.TableName.valueOf(TableName.java:261)
> at
> org.apache.hadoop.hbase.regionserver.wal.HLogKey.readFields(HLogKey.java:338)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1898)
> at
> org.apache.hadoop.io.SequenceFile$Reader.next(SequenceFile.java:1938)
> at
> org.apache.hadoop.hbase.regionserver.wal.SequenceFileLogReader.readNext(SequenceFileLogReader.java:215)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBase.java:98)
> at
> org.apache.hadoop.hbase.regionserver.wal.ReaderBase.next(ReaderBas
[jira] [Commented] (HBASE-9321) Contention getting the current user in RpcClient$Connection.writeRequest
[
https://issues.apache.org/jira/browse/HBASE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749612#comment-13749612
]
Hadoop QA commented on HBASE-9321:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599743/trunk-9321.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6874//console
This message is automatically generated.
> Contention getting the current user in RpcClient$Connection.writeRequest
>
>
> Key: HBASE-9321
> URL: https://issues.apache.org/jira/browse/HBASE-9321
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Jean-Daniel Cryans
> Fix For: 0.98.0, 0.96.0
>
> Attachments: trunk-9321.patch
>
>
> I've been running tests on clusters with "lots" of regions, about 400, and
> I'm seeing weird contention in the client.
> This one I see a lot, hundreds and sometimes thousands of threads are blocked
> like this:
> {noformat}
> "htable-pool4-t74" daemon prio=10 tid=0x7f2254114000 nid=0x2a99 waiting
> for monitor entry [0x7f21f9e94000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:466)
> - waiting to lock <0xfb5ad000> (a java.lang.Class for
> org.apache.hadoop.security.UserGroupInformation)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$Connection.writeRequest(RpcClient.java:1013)
> at org.apache.hadoop.hbase.ipc.RpcClient.call(RpcClient.java:1407)
> at
> org.apache.hadoop.hbase.ipc.RpcClient.callBlockingMethod(RpcClient.java:1634)
> at
> org.apache.hadoop.hbase.ipc.RpcClient$BlockingRpcChannelImplementation.callBlockingMethod(RpcClient.java:1691)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.multi(ClientProtos.java:27339)
> at
> org.apache.hadoop.hbase.client.MultiServerCallable.call(MultiServerCallable.java:105
[jira] [Commented] (HBASE-9328) Table web UI is corrupted sometime
[
https://issues.apache.org/jira/browse/HBASE-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749602#comment-13749602
]
Hadoop QA commented on HBASE-9328:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599782/HBASE-9328-v1-trunk.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/6873//console
This message is automatically generated.
> Table web UI is corrupted sometime
> --
>
> Key: HBASE-9328
> URL: https://issues.apache.org/jira/browse/HBASE-9328
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.98.0, 0.95.2, 0.94.11
>Reporter: Jimmy Xiang
>Assignee: Jean-Marc Spaggiari
> Labels: web-ui
> Attachments: HBASE-9328-v0-trunk.patch, HBASE-9328-v1-trunk.patch,
> table.png
>
>
> The web UI page source is like below:
> {noformat}
> Table Attributes
>
>
> Attribute Name
> Value
> Description
>
>
> Enabled
> true
> Is the table enabled
>
>
> Compaction
>
>
> {noformat}
> No sure if it is a HBase issue, or a network/browser issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9116) Add a view/edit tool for favored node mappings for regions
[
https://issues.apache.org/jira/browse/HBASE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749600#comment-13749600
]
Hadoop QA commented on HBASE-9116:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599715/9116-3.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 6 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 4 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6871//console
This message is automatically generated.
> Add a view/edit tool for favored node mappings for regions
> --
>
> Key: HBASE-9116
> URL: https://issues.apache.org/jira/browse/HBASE-9116
> Project: HBase
> Issue Type: Improvement
> Components: Region Assignment
>Affects Versions: 0.95.0
>Reporter: Devaraj Das
>Assignee: Devaraj Das
> Fix For: 0.96.0
>
> Attachments: 9116-1.txt, 9116-2.txt, 9116-2.txt, 9116-2.txt,
> 9116-3.txt
>
>
> Add a tool that one can run offline to view the favored node mappings for
> regions, and also fix the mappings if needed. Such a tool exists in the
> 0.89-fb branch. Will port it over to trunk/0.95.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-6581) Build with hadoop.profile=3.0
[
https://issues.apache.org/jira/browse/HBASE-6581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749601#comment-13749601
]
Hadoop QA commented on HBASE-6581:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599627/HBASE-6581-3.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 3 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6872//console
This message is automatically generated.
> Build with hadoop.profile=3.0
> -
>
> Key: HBASE-6581
> URL: https://issues.apache.org/jira/browse/HBASE-6581
> Project: HBase
> Issue Type: Bug
>Reporter: Eric Charles
>Assignee: Eric Charles
> Attachments: HBASE-6581-1.patch, HBASE-6581-20130821.patch,
> HBASE-6581-2.patch, HBASE-6581-3.patch, HBASE-6581.diff, HBASE-6581.diff
>
>
> Building trunk with hadoop.profile=3.0 gives exceptions (see [1]) due to
> change in the hadoop maven modules naming (and also usage of 3.0-SNAPSHOT
> instead of 3.0.0-SNAPSHOT in hbase-common).
> I can provide a patch that would move most of hadoop dependencies in their
> respective profiles and will define the correct hadoop deps in the 3.0
> profile.
> Please tell me if that's ok to go this way.
> Thx, Eric
> [1]
> $ mvn clean install -Dhadoop.profile=3.0
> [INFO] Scanning for projects...
> [ERROR] The build could not read 3 projects -> [Help 1]
> [ERROR]
> [ERROR] The project org.apache.hbase:hbase-server:0.95-SNAPSHOT
> (/d/hbase.svn/hbase-server/pom.xml) has 3 errors
> [ERROR] 'dependencies.dependency.version' for
> org.apache.hadoop:hadoop-common:jar is missing. @ line 655, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.apache.hadoop:hadoop-annotations:jar is missing. @ line 659, column 21
> [ERROR] 'dependencies.dependency.version' for
> org.apache.hadoop:hadoop-minicluster:jar is missing. @ line 663, column 21
> [ERROR]
> [ERROR] The project org.apache.hbase:hbase-common:0.95-SNAPSHOT
> (/d/hbase.svn/hbase-common/pom.xml) has 3 errors
> [ERROR] 'dependencies.dependency.version' for
> org
[jira] [Commented] (HBASE-9317) Define timeout period for TestHBaseFsck#testSplitDaughtersNotInMeta
[
https://issues.apache.org/jira/browse/HBASE-9317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749581#comment-13749581
]
Hadoop QA commented on HBASE-9317:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599808/9317-v2.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:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
{color:red}-1 core zombie tests{color}. There are 1 zombie test(s):
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6869//console
This message is automatically generated.
> Define timeout period for TestHBaseFsck#testSplitDaughtersNotInMeta
> ---
>
> Key: HBASE-9317
> URL: https://issues.apache.org/jira/browse/HBASE-9317
> Project: HBase
> Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
> Attachments: 9317-v1.txt, 9317-v2.txt
>
>
> In hbase-0.95-on-hadoop2 build #247, TestHBaseFsck hung in
> testSplitDaughtersNotInMeta.
> This sub-task defines timeout period for
> TestHBaseFsck#testSplitDaughtersNotInMeta so that long running test would be
> timed out instead of hanging.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-9332) OrderedBytes does not decode Strings correctly
[
https://issues.apache.org/jira/browse/HBASE-9332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749580#comment-13749580
]
Hadoop QA commented on HBASE-9332:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599739/0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 4 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:red}-1 release audit{color}. The applied patch generated 2 release
audit warnings (more than the trunk's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6870//console
This message is automatically generated.
> OrderedBytes does not decode Strings correctly
> --
>
> Key: HBASE-9332
> URL: https://issues.apache.org/jira/browse/HBASE-9332
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.95.2
>Reporter: Nick Dimiduk
>Assignee: Nick Dimiduk
> Fix For: 0.98.0, 0.96.0
>
> Attachments: 0001-HBASE-9332-OrderedBytes-error-decoding-strings.patch
>
>
> While writing a test describing the expected behavior for HBASE-9283, I
> discovered an error in String decoding. The error occurs when the string
> being decoded does not start at position 0. The unit tests were originally
> designed to cover this scenario, but this condition slipped in the transition
> to PositionedByteBuffer.
> Update the tests to cover this scenario and fix the String decoding logic.
> String appears to be the only codec affected. This error is only in decoding
> -- encoding produces correct byte[].
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-4811) Support reverse Scan
[
https://issues.apache.org/jira/browse/HBASE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749553#comment-13749553
]
Hadoop QA commented on HBASE-4811:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599757/4811-0.94-v3.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 19 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/6868//console
This message is automatically generated.
> 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-0.94-v3.txt, 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] [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=13749550#comment-13749550
]
Hadoop QA commented on HBASE-7709:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12599751/HBASE-7709-rev5.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/6866//console
This message is automatically generated.
> Infinite loop possible in Master/Master replication
> ---
>
> Key: HBASE-7709
> URL: https://issues.apache.org/jira/browse/HBASE-7709
> Project: HBase
> Issue Type: Bug
> Components: Replication
>Affects Versions: 0.94.6, 0.95.1
>Reporter: Lars Hofhansl
>Assignee: Vasu Mariyala
> Fix For: 0.98.0, 0.94.12, 0.96.0
>
> Attachments: 095-trunk.patch, 0.95-trunk-rev1.patch,
> 0.95-trunk-rev2.patch, 0.95-trunk-rev3.patch, 0.95-trunk-rev4.patch,
> HBASE-7709.patch, HBASE-7709-rev1.patch, HBASE-7709-rev2.patch,
> HBASE-7709-rev3.patch, HBASE-7709-rev4.patch, HBASE-7709-rev5.patch
>
>
> We just discovered the following scenario:
> # Cluster A and B are setup in master/master replication
> # By accident we had Cluster C replicate to Cluster A.
> Now all edit originating from C will be bouncing between A and B. Forever!
> The reason is that when the edit come in from C the cluster ID is already set
> and won't be reset.
> We have a couple of options here:
> # Optionally only support master/master (not cycles of more than two
> clusters). In that case we can always reset the cluster ID in the
> ReplicationSource. That means that now cycles > 2 will have the data cycle
> forever. This is the only option that requires no changes in the HLog format.
> # Instead of a single cluster id per edit maintain a (unordered) set of
> cluster id that have seen this edit. Then in ReplicationSource we drop any
> edit that the sink has seen already. The is the cleanest approach, but it
> might need a lot of data stored per edit if there are many clusters involved.
> # Maintain a configurable counter of the maximum cycle side we want to
> support. Could default to 10 (even maybe even just). Store a hop-count in the
> WAL and the ReplicationSource increases that hop-count on each hop. If we're
> over the max, just drop the edit.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
