[jira] [Commented] (HBASE-7801) Allow a deferred sync option per Mutation.
[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604139#comment-13604139
]
Hadoop QA commented on HBASE-7801:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12573996/7801-0.96-full-v4.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 153
new or modified tests.
{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 6
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces lines longer than
100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4847//console
This message is automatically generated.
> Allow a deferred sync option per Mutation.
> --
>
> Key: HBASE-7801
> URL: https://issues.apache.org/jira/browse/HBASE-7801
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 0.95.0, 0.94.6
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt,
> 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt,
> 7801-0.96-v1.txt
>
>
> Won't have time for parent. But a deferred sync option on a per operation
> basis comes up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a
> special mutation attribute.
> For batch operation we'd take the safest sync option of any of the mutations.
> I.e. if there is at least one that wants to be flushed we'd sync the batch,
> if there's none of those but at least one that wants deferred flush we defer
> flush the batch, 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-8081) Backport HBASE-7213 (separate hlog for meta tables) to 0.94
[ https://issues.apache.org/jira/browse/HBASE-8081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604141#comment-13604141 ] Ted Yu commented on HBASE-8081: --- I have run test suite with option disabled (default). Result was green. > Backport HBASE-7213 (separate hlog for meta tables) to 0.94 > --- > > Key: HBASE-8081 > URL: https://issues.apache.org/jira/browse/HBASE-8081 > Project: HBase > Issue Type: Bug >Affects Versions: 0.94.5 >Reporter: Devaraj Das >Assignee: Devaraj Das > Fix For: 0.94.7 > > Attachments: 7213-0.94-2.patch, 7213-0.94-3.patch, 7213-0.94.patch, > 7213-0.94-with-config.patch > > > I am interested in backporting HBASE-7213 to 0.94. Helps to address more of > the MTTR story. Offline discussion with Lars indicated he is interested as > well. -- This message is automatically generated by JIRA. If 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-8106) Test to check replication log znodes move is done correctly
[
https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604143#comment-13604143
]
Ted Yu commented on HBASE-8106:
---
{code}
854 p0r 8099-trunk-v4.patch
856 p0 8106-rep-test-trunk-v2.patch
857 mt -Dtest=TestReplicationSourceManager
{code}
I got the following:
{code}
testNodeFailoverWorkerCopyQueuesFromRSUsingMulti(org.apache.hadoop.hbase.replication.regionserver.TestReplicationSourceManager)
Time elapsed: 0.112 sec <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<3>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hbase.replication.regionserver.TestReplicationSourceManager.testNodeFailoverWorkerCopyQueuesFromRSUsingMulti(TestReplicationSourceManager.java:263)
{code}
> Test to check replication log znodes move is done correctly
> ---
>
> Key: HBASE-8106
> URL: https://issues.apache.org/jira/browse/HBASE-8106
> Project: HBase
> Issue Type: Test
> Components: Replication
>Affects Versions: 0.94.5
>Reporter: Himanshu Vashishtha
>Assignee: Himanshu Vashishtha
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: 8106.94, 8106-rep-test-trunk-v2.patch,
> HBase-8106-trunk.patch
>
>
> ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a
> regionserver failover environment. This jira is to add that the move is done
> correctly.
--
This message is automatically generated by JIRA.
If 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-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-8106: -- Resolution: Fixed Status: Resolved (was: Patch Available) > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604144#comment-13604144 ] Ted Yu commented on HBASE-8106: --- Integrated to 0.94, 0.95 and trunk. Thanks for the patch, Himanshu. Thanks for the review, Lars. > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-7403) Online Merge
[ https://issues.apache.org/jira/browse/HBASE-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604147#comment-13604147 ] Ted Yu commented on HBASE-7403: --- Thanks for the quick response. I will try to go over the new tests. This is mostly ready to go. > Online Merge > > > Key: HBASE-7403 > URL: https://issues.apache.org/jira/browse/HBASE-7403 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.95.0 >Reporter: chunhui shen >Assignee: chunhui shen >Priority: Critical > Fix For: 0.95.0, 0.98.0 > > Attachments: 7403-trunkv5.patch, 7403-trunkv6.patch, 7403v5.diff, > 7403-v5.txt, 7403v5.txt, hbase-7403-94v1.patch, hbase-7403-trunkv10.patch, > hbase-7403-trunkv11.patch, hbase-7403-trunkv12.patch, > hbase-7403-trunkv13.patch, hbase-7403-trunkv14.patch, > hbase-7403-trunkv15.patch, hbase-7403-trunkv16.patch, > hbase-7403-trunkv19.patch, hbase-7403-trunkv1.patch, > hbase-7403-trunkv20.patch, hbase-7403-trunkv22.patch, > hbase-7403-trunkv23.patch, hbase-7403-trunkv5.patch, > hbase-7403-trunkv6.patch, hbase-7403-trunkv7.patch, hbase-7403-trunkv8.patch, > hbase-7403-trunkv9.patch, merge region.pdf > > > Support executing region merge transaction on Regionserver, similar with > split transaction > Process of merging two regions: > a.client send RPC(dispacth merging regions) to master > b.master move the regions together (on the same regionserver) > c.master send RPC(merge regions) to regionserver > d.Regionserver execute the regions merge transaction in the thread pool > e.the above b,c,d run asynchronously > Process of region merge transaction: > a.Construct a new region merge transaction. > b.prepare for the merge transaction, the transaction will be canceled if it > is unavailable, > e.g. two regions don't belong to same table; two regions are not adjacent in > a non-compulsory merge; region is closed or has reference > c.execute the transaction as the following: > /** > * Set region as in transition, set it into MERGING state. > */ > SET_MERGING_IN_ZK, > /** > * We created the temporary merge data directory. > */ > CREATED_MERGE_DIR, > /** > * Closed the merging region A. > */ > CLOSED_REGION_A, > /** > * The merging region A has been taken out of the server's online regions > list. > */ > OFFLINED_REGION_A, > /** > * Closed the merging region B. > */ > CLOSED_REGION_B, > /** > * The merging region B has been taken out of the server's online regions > list. > */ > OFFLINED_REGION_B, > /** > * Started in on creation of the merged region. > */ > STARTED_MERGED_REGION_CREATION, > /** > * Point of no return. If we got here, then transaction is not recoverable > * other than by crashing out the regionserver. > */ > PONR > d.roll back if step c throws exception > Usage: > HBaseAdmin#mergeRegions > See more details from the patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-7403) Online Merge
[ https://issues.apache.org/jira/browse/HBASE-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-7403: -- Description: Support executing region merge transaction on Regionserver, similar with split transaction Process of merging two regions: a.client sends RPC (dispatch merging regions) to master b.master moves the regions together (on the same regionserver where the more heavily loaded region resided) c.master sends RPC (merge regions) to this regionserver d.Regionserver executes the region merge transaction in the thread pool e.the above b,c,d run asynchronously Process of region merge transaction: a.Construct a new region merge transaction. b.prepare for the merge transaction, the transaction will be canceled if it is unavailable, e.g. two regions don't belong to same table; two regions are not adjacent in a non-compulsory merge; region is closed or has reference c.execute the transaction as the following: /** * Set region as in transition, set it into MERGING state. */ SET_MERGING_IN_ZK, /** * We created the temporary merge data directory. */ CREATED_MERGE_DIR, /** * Closed the merging region A. */ CLOSED_REGION_A, /** * The merging region A has been taken out of the server's online regions list. */ OFFLINED_REGION_A, /** * Closed the merging region B. */ CLOSED_REGION_B, /** * The merging region B has been taken out of the server's online regions list. */ OFFLINED_REGION_B, /** * Started in on creation of the merged region. */ STARTED_MERGED_REGION_CREATION, /** * Point of no return. If we got here, then transaction is not recoverable * other than by crashing out the regionserver. */ PONR d.roll back if step c throws exception Usage: HBaseAdmin#mergeRegions See more details from the patch was: Support executing region merge transaction on Regionserver, similar with split transaction Process of merging two regions: a.client send RPC(dispacth merging regions) to master b.master move the regions together (on the same regionserver) c.master send RPC(merge regions) to regionserver d.Regionserver execute the regions merge transaction in the thread pool e.the above b,c,d run asynchronously Process of region merge transaction: a.Construct a new region merge transaction. b.prepare for the merge transaction, the transaction will be canceled if it is unavailable, e.g. two regions don't belong to same table; two regions are not adjacent in a non-compulsory merge; region is closed or has reference c.execute the transaction as the following: /** * Set region as in transition, set it into MERGING state. */ SET_MERGING_IN_ZK, /** * We created the temporary merge data directory. */ CREATED_MERGE_DIR, /** * Closed the merging region A. */ CLOSED_REGION_A, /** * The merging region A has been taken out of the server's online regions list. */ OFFLINED_REGION_A, /** * Closed the merging region B. */ CLOSED_REGION_B, /** * The merging region B has been taken out of the server's online regions list. */ OFFLINED_REGION_B, /** * Started in on creation of the merged region. */ STARTED_MERGED_REGION_CREATION, /** * Point of no return. If we got here, then transaction is not recoverable * other than by crashing out the regionserver. */ PONR d.roll back if step c throws exception Usage: HBaseAdmin#mergeRegions See more details from the patch > Online Merge > > > Key: HBASE-7403 > URL: https://issues.apache.org/jira/browse/HBASE-7403 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.95.0 >Reporter: chunhui shen >Assignee: chunhui shen >Priority: Critical > Fix For: 0.95.0, 0.98.0 > > Attachments: 7403-trunkv5.patch, 7403-trunkv6.patch, 7403v5.diff, > 7403-v5.txt, 7403v5.txt, hbase-7403-94v1.patch, hbase-7403-trunkv10.patch, > hbase-7403-trunkv11.patch, hbase-7403-trunkv12.patch, > hbase-7403-trunkv13.patch, hbase-7403-trunkv14.patch, > hbase-7403-trunkv15.patch, hbase-7403-trunkv16.patch, > hbase-7403-trunkv19.patch, hbase-7403-trunkv1.patch, > hbase-7403-trunkv20.patch, hbase-7403-trunkv22.patch, > hbase-7403-trunkv23.patch, hbase-7403-trunkv5.patch, > hbase-7403-trunkv6.patch, hbase-7403-trunkv7.patch, hbase-7403-trunkv8.patch, > hbase-7403-trunkv9.patch, merge region.pdf > > > Support executing region merge transaction on Regionserver, similar with > split transaction > Process of merging two regions: > a.client sends RPC (dispatch merging regions) to master > b.master moves the regions together (on the same regionserver where the more > heavily loaded region resided
[jira] [Commented] (HBASE-7801) Allow a deferred sync option per Mutation.
[ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604159#comment-13604159 ] Ted Yu commented on HBASE-7801: --- Can you take a look at the java of warnings ? Thanks, Lars. > Allow a deferred sync option per Mutation. > -- > > Key: HBASE-7801 > URL: https://issues.apache.org/jira/browse/HBASE-7801 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.95.0, 0.94.6 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, > 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, > 7801-0.96-v1.txt > > > Won't have time for parent. But a deferred sync option on a per operation > basis comes up quite frequently. > In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a > special mutation attribute. > For batch operation we'd take the safest sync option of any of the mutations. > I.e. if there is at least one that wants to be flushed we'd sync the batch, > if there's none of those but at least one that wants deferred flush we defer > flush the batch, 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] [Comment Edited] (HBASE-7801) Allow a deferred sync option per Mutation.
[ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604159#comment-13604159 ] Ted Yu edited comment on HBASE-7801 at 3/16/13 7:59 AM: Can you take a look at the javadoc warnings ? Thanks, Lars. was (Author: yuzhih...@gmail.com): Can you take a look at the java of warnings ? Thanks, Lars. > Allow a deferred sync option per Mutation. > -- > > Key: HBASE-7801 > URL: https://issues.apache.org/jira/browse/HBASE-7801 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.95.0, 0.94.6 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, > 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, > 7801-0.96-v1.txt > > > Won't have time for parent. But a deferred sync option on a per operation > basis comes up quite frequently. > In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a > special mutation attribute. > For batch operation we'd take the safest sync option of any of the mutations. > I.e. if there is at least one that wants to be flushed we'd sync the batch, > if there's none of those but at least one that wants deferred flush we defer > flush the batch, 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-7930) hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER
[ https://issues.apache.org/jira/browse/HBASE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604165#comment-13604165 ] Hudson commented on HBASE-7930: --- Integrated in hbase-0.95 #77 (See [https://builds.apache.org/job/hbase-0.95/77/]) HBASE-7930 hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER (Jean-Marc) (Revision 1457102) Result = FAILURE tedyu : Files : * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * /hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java * /hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java > hbck should provide an option to fix .META. rows with empty > REGIONINFO_QUALIFIER > > > Key: HBASE-7930 > URL: https://issues.apache.org/jira/browse/HBASE-7930 > Project: HBase > Issue Type: Improvement >Reporter: Jean-Marc Spaggiari >Assignee: Jean-Marc Spaggiari > Fix For: 0.95.0, 0.98.0 > > Attachments: HBASE-7930-v0-trunk.patch, HBASE-7930-v1-trunk.patch, > HBASE-7930-v2-trunk.patch > > > Today when master and HBCK are reporting empty REGIONINFO_QUALIFIER .META. > rows, we need to manually delete them from the .META. region. We need to > enhance hbck to do that automatically. -- This message is automatically generated by JIRA. If 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-7809) Refactor Split/Merge to use HRegionFileSystem
[ https://issues.apache.org/jira/browse/HBASE-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604169#comment-13604169 ] Hudson commented on HBASE-7809: --- Integrated in HBase-TRUNK #3963 (See [https://builds.apache.org/job/HBase-TRUNK/3963/]) HBASE-7809 Refactor Split/Merge to use HRegionFileSystem (Revision 1457148) Result = FAILURE mbertozzi : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionFileSystem.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SplitRequest.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SplitTransaction.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/RestoreSnapshotHelper.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HFileArchiveUtil.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/RegionSplitter.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/backup/TestHFileArchiving.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileLinkCleaner.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionFileSystem.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionInfo.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransaction.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreFile.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/snapshot/TestRestoreSnapshotHelper.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/HFileArchiveTestingUtil.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHFileArchiveUtil.java > Refactor Split/Merge to use HRegionFileSystem > - > > Key: HBASE-7809 > URL: https://issues.apache.org/jira/browse/HBASE-7809 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Attachments: HBASE-7809-v0.patch, HBASE-7809-v1.patch, > HBASE-7809-v2.patch, HBASE-7809-v3.patch, HBASE-7809-v4.patch > > > Use the HRegionFileSystem for the fs operations. -- This message is automatically generated by JIRA. If 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-7930) hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER
[ https://issues.apache.org/jira/browse/HBASE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604170#comment-13604170 ] Hudson commented on HBASE-7930: --- Integrated in HBase-TRUNK #3963 (See [https://builds.apache.org/job/HBase-TRUNK/3963/]) HBASE-7930 hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER (Jean-Marc) (Revision 1457103) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java > hbck should provide an option to fix .META. rows with empty > REGIONINFO_QUALIFIER > > > Key: HBASE-7930 > URL: https://issues.apache.org/jira/browse/HBASE-7930 > Project: HBase > Issue Type: Improvement >Reporter: Jean-Marc Spaggiari >Assignee: Jean-Marc Spaggiari > Fix For: 0.95.0, 0.98.0 > > Attachments: HBASE-7930-v0-trunk.patch, HBASE-7930-v1-trunk.patch, > HBASE-7930-v2-trunk.patch > > > Today when master and HBCK are reporting empty REGIONINFO_QUALIFIER .META. > rows, we need to manually delete them from the .META. region. We need to > enhance hbck to do that automatically. -- This message is automatically generated by JIRA. If 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-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604171#comment-13604171 ] Hudson commented on HBASE-8106: --- Integrated in HBase-TRUNK #3963 (See [https://builds.apache.org/job/HBase-TRUNK/3963/]) HBASE-8106 Test to check replication log znodes move is done correctly (Himanshu) (Revision 1457216) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-8034) record on-disk data size for store file and make it available during writing
[ https://issues.apache.org/jira/browse/HBASE-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604172#comment-13604172 ] Hudson commented on HBASE-8034: --- Integrated in HBase-TRUNK #3963 (See [https://builds.apache.org/job/HBase-TRUNK/3963/]) REVERT HBASE-8034 record on-disk data size for store file and make it available during writing (Revision 1457193) Result = FAILURE sershe : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileWriter.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java > record on-disk data size for store file and make it available during writing > > > Key: HBASE-8034 > URL: https://issues.apache.org/jira/browse/HBASE-8034 > Project: HBase > Issue Type: Task >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Minor > Attachments: HBASE-8034-v0.patch, HBASE-8034-v1.patch, > HBASE-8034-v2.patch > > > To better estimate the size of data in the file, and to be able to split > files intelligently during any multi-file compactor like stripe or level. -- This message is automatically generated by JIRA. If 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-7809) Refactor Split/Merge to use HRegionFileSystem
[ https://issues.apache.org/jira/browse/HBASE-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604173#comment-13604173 ] Hudson commented on HBASE-7809: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) HBASE-7809 Refactor Split/Merge to use HRegionFileSystem (Revision 1457148) Result = FAILURE mbertozzi : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/backup/HFileArchiver.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionFileSystem.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SplitRequest.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SplitTransaction.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/snapshot/RestoreSnapshotHelper.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HFileArchiveUtil.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/RegionSplitter.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/backup/TestHFileArchiving.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/master/cleaner/TestHFileLinkCleaner.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionFileSystem.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionInfo.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestSplitTransaction.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreFile.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestWALReplay.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/snapshot/TestRestoreSnapshotHelper.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/HFileArchiveTestingUtil.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHFileArchiveUtil.java > Refactor Split/Merge to use HRegionFileSystem > - > > Key: HBASE-7809 > URL: https://issues.apache.org/jira/browse/HBASE-7809 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Attachments: HBASE-7809-v0.patch, HBASE-7809-v1.patch, > HBASE-7809-v2.patch, HBASE-7809-v3.patch, HBASE-7809-v4.patch > > > Use the HRegionFileSystem for the fs operations. -- This message is automatically generated by JIRA. If 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-8118) TestTablePermission depends on the execution order
[
https://issues.apache.org/jira/browse/HBASE-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604174#comment-13604174
]
Hudson commented on HBASE-8118:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/])
HBASE-8118 TestTablePermission depends on the execution order (Revision
1456946)
Result = FAILURE
mbertozzi :
Files :
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java
> TestTablePermission depends on the execution order
> --
>
> Key: HBASE-8118
> URL: https://issues.apache.org/jira/browse/HBASE-8118
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.95.0, 0.94.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.94.5, 0.94.7
>
> Attachments: HBASE-8118-v0.patch
>
>
> All the tests changes the _acl_ table but they don't clear the state.
> If testGlobalPermission() runs before testBasicWrite() you end up with
> {code}
> java.lang.AssertionError: Full permission map should have entries for both
> test tables expected:<2> but was:<3>
> 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.apache.hadoop.hbase.security.access.TestTablePermissions.testBasicWrite(TestTablePermissions.java:181)
> {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-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[ https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604175#comment-13604175 ] Hudson commented on HBASE-8101: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) HBASE-8101 Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc. (Revision 1457024) Result = FAILURE stack : Files : * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/CatalogTracker.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Action.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Append.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Get.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Increment.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/WrongRowIOException.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/AccessDeniedException.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/CoprocessorException.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/CorruptHFileException.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/DoNotRetryIOException.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/LeaseException.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/NullComparator.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/security/AuthMethod.java * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java * /hbase/trunk/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAttributes.java * /hbase/trunk/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestGet.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/CellComparator.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValue.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/BaseDecoder.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/BaseEncoder.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/CellCodec.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/KeyValueCodec.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/ByteBufferOutputStream.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/util/test/RedundantKVGenerator.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/DemoClient.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionSourceImpl.java * /hbase/trunk/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionSourceImpl.java * /hbase/trunk/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/ImportTsv.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/KeyValueSortReducer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/master/handler/DeleteTableHandler.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/thrift/IncrementCoalescer.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/ByteBufferOutputStream.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/TestZooKeeper.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/catalog/TestMetaReaderEditor.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromCli
[jira] [Commented] (HBASE-8117) Remove redundant byte conversion methods from HConstants
[ https://issues.apache.org/jira/browse/HBASE-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604176#comment-13604176 ] Hudson commented on HBASE-8117: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) HBASE-8117 Remove redundant byte conversion methods from HConstants (Nick Dimiduk) (Revision 1457045) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java > Remove redundant byte conversion methods from HConstants > > > Key: HBASE-8117 > URL: https://issues.apache.org/jira/browse/HBASE-8117 > Project: HBase > Issue Type: Improvement > Components: util >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk >Priority: Trivial > Fix For: 0.95.0, 0.98.0 > > Attachments: > 0001-HBASE-8117-remove-redundant-byte-conversion-methods.patch > > > HConstants#toBytes and HConstants#toString are identical implementations to > implementations in Bytes. Consolidate. -- This message is automatically generated by JIRA. If 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-7930) hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER
[ https://issues.apache.org/jira/browse/HBASE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604177#comment-13604177 ] Hudson commented on HBASE-7930: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) HBASE-7930 hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER (Jean-Marc) (Revision 1457103) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java > hbck should provide an option to fix .META. rows with empty > REGIONINFO_QUALIFIER > > > Key: HBASE-7930 > URL: https://issues.apache.org/jira/browse/HBASE-7930 > Project: HBase > Issue Type: Improvement >Reporter: Jean-Marc Spaggiari >Assignee: Jean-Marc Spaggiari > Fix For: 0.95.0, 0.98.0 > > Attachments: HBASE-7930-v0-trunk.patch, HBASE-7930-v1-trunk.patch, > HBASE-7930-v2-trunk.patch > > > Today when master and HBCK are reporting empty REGIONINFO_QUALIFIER .META. > rows, we need to manually delete them from the .META. region. We need to > enhance hbck to do that automatically. -- This message is automatically generated by JIRA. If 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-8122) TestAccessController depends on the execution order
[
https://issues.apache.org/jira/browse/HBASE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604178#comment-13604178
]
Hudson commented on HBASE-8122:
---
Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/])
HBASE-8122 TestAccessController depends on the execution order (Revision
1457091)
Result = FAILURE
mbertozzi :
Files :
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
> TestAccessController depends on the execution order
> ---
>
> Key: HBASE-8122
> URL: https://issues.apache.org/jira/browse/HBASE-8122
> Project: HBase
> Issue Type: Bug
> Components: security, test
>Affects Versions: 0.95.0, 0.94.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.95.0
>
> Attachments: HBASE-8122-v1.patch
>
>
> If testGrantRevoke() runs before testRead() you end up with, since
> testGrantRevoke() revokes the read right for the rouser.
> {code}
> testRead(org.apache.hadoop.hbase.security.access.TestAccessController) Time
> elapsed: 5.992 sec <<< FAILURE!
> java.lang.AssertionError: Expected action to pass for user 'rouser' but was
> denied
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.verifyAllowed(TestAccessController.java:204)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.verifyAllowed(TestAccessController.java:211)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.verifyRead(TestAccessController.java:600)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.testRead(TestAccessController.java:627)
> {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-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604179#comment-13604179 ] Hudson commented on HBASE-8106: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) HBASE-8106 Test to check replication log znodes move is done correctly (Himanshu) (Revision 1457216) Result = FAILURE tedyu : Files : * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-8123) Replace HashMap/HashSet with TreeMap/TreeSet where byte[] is used as key
[ https://issues.apache.org/jira/browse/HBASE-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604180#comment-13604180 ] Hudson commented on HBASE-8123: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) HBASE-8123 Replace HashMap/HashSet with TreeMap/TreeSet where byte[] is used as key (Revision 1457089) Result = FAILURE mbertozzi : Files : * /hbase/trunk/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableMultiplexer.java * /hbase/trunk/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce/IndexBuilder.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/PutCombiner.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLog.java > Replace HashMap/HashSet with TreeMap/TreeSet where byte[] is used as key > > > Key: HBASE-8123 > URL: https://issues.apache.org/jira/browse/HBASE-8123 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.0, 0.94.5 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.95.0 > > Attachments: HBASE-8123-v0-94.patch, HBASE-8123-v0.patch, > HBASE-8123-v1.patch > > > We still have code using HashMap/HashSet with byte[] as key -- This message is automatically generated by JIRA. If 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-8034) record on-disk data size for store file and make it available during writing
[ https://issues.apache.org/jira/browse/HBASE-8034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604181#comment-13604181 ] Hudson commented on HBASE-8034: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) REVERT HBASE-8034 record on-disk data size for store file and make it available during writing (Revision 1457193) Result = FAILURE sershe : Files : * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/AbstractHFileWriter.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreFile.java > record on-disk data size for store file and make it available during writing > > > Key: HBASE-8034 > URL: https://issues.apache.org/jira/browse/HBASE-8034 > Project: HBase > Issue Type: Task >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin >Priority: Minor > Attachments: HBASE-8034-v0.patch, HBASE-8034-v1.patch, > HBASE-8034-v2.patch > > > To better estimate the size of data in the file, and to be able to split > files intelligently during any multi-file compactor like stripe or level. -- This message is automatically generated by JIRA. If 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-4285) partitions file created in user's home directory by importtsv
[ https://issues.apache.org/jira/browse/HBASE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604182#comment-13604182 ] Hudson commented on HBASE-4285: --- Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #449 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/449/]) HBASE-4285 partitions file created in user's home directory by importtsv (Revision 1457078) Result = FAILURE stack : Files : * /hbase/trunk/hbase-it/src/test/java/org/apache/hadoop/hbase/mapreduce/IntegrationTestImportTsv.java * /hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/HFileOutputFormat.java > partitions file created in user's home directory by importtsv > - > > Key: HBASE-4285 > URL: https://issues.apache.org/jira/browse/HBASE-4285 > Project: HBase > Issue Type: Sub-task > Components: mapreduce >Affects Versions: 0.90.4, 0.95.0, 0.98.0 >Reporter: Wing Yew Poon >Assignee: Nick Dimiduk > Fix For: 0.95.0, 0.98.0 > > Attachments: > 0001-HBASE-4285-cleanup-ImportTsv-partitions-file-litter.patch, > 0001-HBASE-4285-cleanup-ImportTsv-partitions-file-litter.patch, > 0001-HBASE-4285-cleanup-ImportTsv-partitions-file-litter.patch > > > I am using HBase 0.94 from CDH3u1. > After running importtsv, I find that a temporary partitions_* file is written > to my user home directory in HDFS. This file should really be deleted > automatically when it is no longer needed. -- This message is automatically generated by JIRA. If 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-8118) TestTablePermission depends on the execution order
[
https://issues.apache.org/jira/browse/HBASE-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604189#comment-13604189
]
Hudson commented on HBASE-8118:
---
Integrated in hbase-0.95-on-hadoop2 #28 (See
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/])
HBASE-8118 TestTablePermission depends on the execution order (Revision
1456948)
Result = FAILURE
mbertozzi :
Files :
*
/hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java
> TestTablePermission depends on the execution order
> --
>
> Key: HBASE-8118
> URL: https://issues.apache.org/jira/browse/HBASE-8118
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.95.0, 0.94.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.94.5, 0.94.7
>
> Attachments: HBASE-8118-v0.patch
>
>
> All the tests changes the _acl_ table but they don't clear the state.
> If testGlobalPermission() runs before testBasicWrite() you end up with
> {code}
> java.lang.AssertionError: Full permission map should have entries for both
> test tables expected:<2> but was:<3>
> 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.apache.hadoop.hbase.security.access.TestTablePermissions.testBasicWrite(TestTablePermissions.java:181)
> {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-8101) Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc.
[ https://issues.apache.org/jira/browse/HBASE-8101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604190#comment-13604190 ] Hudson commented on HBASE-8101: --- Integrated in hbase-0.95-on-hadoop2 #28 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/]) HBASE-8101 Cleanup: findbugs and javadoc warning fixes as well as making it illegal passing null row to Put/Delete, etc. (Revision 1457027) Result = FAILURE stack : Files : * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/catalog/CatalogTracker.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Action.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Append.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Get.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Increment.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Mutation.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Put.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/RowMutations.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/WrongRowIOException.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/AccessDeniedException.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/CoprocessorException.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/CorruptHFileException.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/DoNotRetryIOException.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/exceptions/LeaseException.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/filter/NullComparator.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/security/AuthMethod.java * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZKUtil.java * /hbase/branches/0.95/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestAttributes.java * /hbase/branches/0.95/hbase-client/src/test/java/org/apache/hadoop/hbase/client/TestGet.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/CellComparator.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValue.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/BaseDecoder.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/BaseEncoder.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/CellCodec.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/codec/KeyValueCodec.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/io/ByteBufferOutputStream.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/DiffKeyDeltaEncoder.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/io/encoding/PrefixKeyDeltaEncoder.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/util/test/RedundantKVGenerator.java * /hbase/branches/0.95/hbase-examples/src/main/java/org/apache/hadoop/hbase/thrift/DemoClient.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionSourceImpl.java * /hbase/branches/0.95/hbase-hadoop1-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/hbase/regionserver/MetricsRegionSourceImpl.java * /hbase/branches/0.95/hbase-hadoop2-compat/src/main/java/org/apache/hadoop/metrics2/impl/JmxCacheBuster.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/HBaseServer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/ImportTsv.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/KeyValueSortReducer.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/master/handler/DeleteTableHandler.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/thrift/IncrementCoalescer.java * /hbase/branches/0.95/hbase-server/src/
[jira] [Commented] (HBASE-8117) Remove redundant byte conversion methods from HConstants
[ https://issues.apache.org/jira/browse/HBASE-8117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604191#comment-13604191 ] Hudson commented on HBASE-8117: --- Integrated in hbase-0.95-on-hadoop2 #28 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/]) HBASE-8117 Remove redundant byte conversion methods from HConstants (Nick Dimiduk) (Revision 1457044) Result = FAILURE tedyu : Files : * /hbase/branches/0.95/hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java > Remove redundant byte conversion methods from HConstants > > > Key: HBASE-8117 > URL: https://issues.apache.org/jira/browse/HBASE-8117 > Project: HBase > Issue Type: Improvement > Components: util >Reporter: Nick Dimiduk >Assignee: Nick Dimiduk >Priority: Trivial > Fix For: 0.95.0, 0.98.0 > > Attachments: > 0001-HBASE-8117-remove-redundant-byte-conversion-methods.patch > > > HConstants#toBytes and HConstants#toString are identical implementations to > implementations in Bytes. Consolidate. -- This message is automatically generated by JIRA. If 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-7930) hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER
[ https://issues.apache.org/jira/browse/HBASE-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604192#comment-13604192 ] Hudson commented on HBASE-7930: --- Integrated in hbase-0.95-on-hadoop2 #28 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/]) HBASE-7930 hbck should provide an option to fix .META. rows with empty REGIONINFO_QUALIFIER (Jean-Marc) (Revision 1457102) Result = FAILURE tedyu : Files : * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * /hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestHBaseFsck.java * /hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/util/hbck/HbckTestingUtil.java > hbck should provide an option to fix .META. rows with empty > REGIONINFO_QUALIFIER > > > Key: HBASE-7930 > URL: https://issues.apache.org/jira/browse/HBASE-7930 > Project: HBase > Issue Type: Improvement >Reporter: Jean-Marc Spaggiari >Assignee: Jean-Marc Spaggiari > Fix For: 0.95.0, 0.98.0 > > Attachments: HBASE-7930-v0-trunk.patch, HBASE-7930-v1-trunk.patch, > HBASE-7930-v2-trunk.patch > > > Today when master and HBCK are reporting empty REGIONINFO_QUALIFIER .META. > rows, we need to manually delete them from the .META. region. We need to > enhance hbck to do that automatically. -- This message is automatically generated by JIRA. If 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-8122) TestAccessController depends on the execution order
[
https://issues.apache.org/jira/browse/HBASE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604193#comment-13604193
]
Hudson commented on HBASE-8122:
---
Integrated in hbase-0.95-on-hadoop2 #28 (See
[https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/])
HBASE-8122 TestAccessController depends on the execution order (Revision
1457094)
Result = FAILURE
mbertozzi :
Files :
*
/hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java
> TestAccessController depends on the execution order
> ---
>
> Key: HBASE-8122
> URL: https://issues.apache.org/jira/browse/HBASE-8122
> Project: HBase
> Issue Type: Bug
> Components: security, test
>Affects Versions: 0.95.0, 0.94.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.95.0
>
> Attachments: HBASE-8122-v1.patch
>
>
> If testGrantRevoke() runs before testRead() you end up with, since
> testGrantRevoke() revokes the read right for the rouser.
> {code}
> testRead(org.apache.hadoop.hbase.security.access.TestAccessController) Time
> elapsed: 5.992 sec <<< FAILURE!
> java.lang.AssertionError: Expected action to pass for user 'rouser' but was
> denied
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.verifyAllowed(TestAccessController.java:204)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.verifyAllowed(TestAccessController.java:211)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.verifyRead(TestAccessController.java:600)
> at
> org.apache.hadoop.hbase.security.access.TestAccessController.testRead(TestAccessController.java:627)
> {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-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604194#comment-13604194 ] Hudson commented on HBASE-8106: --- Integrated in hbase-0.95-on-hadoop2 #28 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/]) HBASE-8106 Test to check replication log znodes move is done correctly (Himanshu) (Revision 1457217) Result = FAILURE tedyu : Files : * /hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-8123) Replace HashMap/HashSet with TreeMap/TreeSet where byte[] is used as key
[ https://issues.apache.org/jira/browse/HBASE-8123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604195#comment-13604195 ] Hudson commented on HBASE-8123: --- Integrated in hbase-0.95-on-hadoop2 #28 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/]) HBASE-8123 Replace HashMap/HashSet with TreeMap/TreeSet where byte[] is used as key (Revision 1457090) Result = FAILURE mbertozzi : Files : * /hbase/branches/0.95/hbase-client/src/main/java/org/apache/hadoop/hbase/client/HTableMultiplexer.java * /hbase/branches/0.95/hbase-examples/src/main/java/org/apache/hadoop/hbase/mapreduce/IndexBuilder.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/PutCombiner.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * /hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/TestHLog.java > Replace HashMap/HashSet with TreeMap/TreeSet where byte[] is used as key > > > Key: HBASE-8123 > URL: https://issues.apache.org/jira/browse/HBASE-8123 > Project: HBase > Issue Type: Bug >Affects Versions: 0.95.0, 0.94.5 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi > Fix For: 0.95.0 > > Attachments: HBASE-8123-v0-94.patch, HBASE-8123-v0.patch, > HBASE-8123-v1.patch > > > We still have code using HashMap/HashSet with byte[] as key -- This message is automatically generated by JIRA. If 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-4285) partitions file created in user's home directory by importtsv
[ https://issues.apache.org/jira/browse/HBASE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604196#comment-13604196 ] Hudson commented on HBASE-4285: --- Integrated in hbase-0.95-on-hadoop2 #28 (See [https://builds.apache.org/job/hbase-0.95-on-hadoop2/28/]) HBASE-4285 partitions file created in user's home directory by importtsv (Revision 1457079) Result = FAILURE stack : Files : * /hbase/branches/0.95/hbase-it/src/test/java/org/apache/hadoop/hbase/mapreduce/IntegrationTestImportTsv.java * /hbase/branches/0.95/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/HFileOutputFormat.java > partitions file created in user's home directory by importtsv > - > > Key: HBASE-4285 > URL: https://issues.apache.org/jira/browse/HBASE-4285 > Project: HBase > Issue Type: Sub-task > Components: mapreduce >Affects Versions: 0.90.4, 0.95.0, 0.98.0 >Reporter: Wing Yew Poon >Assignee: Nick Dimiduk > Fix For: 0.95.0, 0.98.0 > > Attachments: > 0001-HBASE-4285-cleanup-ImportTsv-partitions-file-litter.patch, > 0001-HBASE-4285-cleanup-ImportTsv-partitions-file-litter.patch, > 0001-HBASE-4285-cleanup-ImportTsv-partitions-file-litter.patch > > > I am using HBase 0.94 from CDH3u1. > After running importtsv, I find that a temporary partitions_* file is written > to my user home directory in HDFS. This file should really be deleted > automatically when it is no longer needed. -- This message is automatically generated by JIRA. If 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-7992) provide pre/post region offline hooks for HMaster.offlineRegion().
[ https://issues.apache.org/jira/browse/HBASE-7992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604197#comment-13604197 ] Anoop Sam John commented on HBASE-7992: --- +1 Any concerns from your side Ram? > provide pre/post region offline hooks for HMaster.offlineRegion(). > --- > > Key: HBASE-7992 > URL: https://issues.apache.org/jira/browse/HBASE-7992 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Affects Versions: 0.95.0 >Reporter: rajeshbabu >Assignee: rajeshbabu > Fix For: 0.98.0 > > Attachments: HBASE-7992_trunk_2.patch, HBASE-7992_trunk.patch > > > presently no hooks to provide access control to offline region in master. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work started] (HBASE-7984) Use contains(byte[],byte[]) API added into org.apache.hadoop.hbase.util.Bytes at HTable#isValidMetaTableRow()
[ https://issues.apache.org/jira/browse/HBASE-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-7984 started by Anoop Sam John. > Use contains(byte[],byte[]) API added into org.apache.hadoop.hbase.util.Bytes > at HTable#isValidMetaTableRow() > - > > Key: HBASE-7984 > URL: https://issues.apache.org/jira/browse/HBASE-7984 > Project: HBase > Issue Type: Task >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Trivial > Fix For: 0.95.0, 0.98.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Work stopped] (HBASE-7984) Use contains(byte[],byte[]) API added into org.apache.hadoop.hbase.util.Bytes at HTable#isValidMetaTableRow()
[ https://issues.apache.org/jira/browse/HBASE-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-7984 stopped by Anoop Sam John. > Use contains(byte[],byte[]) API added into org.apache.hadoop.hbase.util.Bytes > at HTable#isValidMetaTableRow() > - > > Key: HBASE-7984 > URL: https://issues.apache.org/jira/browse/HBASE-7984 > Project: HBase > Issue Type: Task >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Trivial > Fix For: 0.95.0, 0.98.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (HBASE-7984) Use contains(byte[],byte[]) API added into org.apache.hadoop.hbase.util.Bytes at HTable#isValidMetaTableRow()
[ https://issues.apache.org/jira/browse/HBASE-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John resolved HBASE-7984. --- Resolution: Invalid Release Note: HBASE-7928 is backed out now making this issue invalid > Use contains(byte[],byte[]) API added into org.apache.hadoop.hbase.util.Bytes > at HTable#isValidMetaTableRow() > - > > Key: HBASE-7984 > URL: https://issues.apache.org/jira/browse/HBASE-7984 > Project: HBase > Issue Type: Task >Reporter: Anoop Sam John >Assignee: Anoop Sam John >Priority: Trivial > Fix For: 0.95.0, 0.98.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-4955) Use the official versions of surefire & junit
[ https://issues.apache.org/jira/browse/HBASE-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-4955: --- Status: Open (was: Patch Available) > Use the official versions of surefire & junit > - > > Key: HBASE-4955 > URL: https://issues.apache.org/jira/browse/HBASE-4955 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Fix For: 0.95.0 > > Attachments: 4955.v1.patch, 4955.v2.patch, 4955.v2.patch > > > We currently use private versions for Surefire & JUnit since HBASE-4763. > This JIRA traks what we need to move to official versions. > Surefire 2.11 is just out, but, after some tests, it does not contain all > what we need. > JUnit. Could be for JUnit 4.11. Issue to monitor: > https://github.com/KentBeck/junit/issues/359: fixed in our version, no > feedback for an integration on trunk > Surefire: Could be for Surefire 2.12. Issues to monitor are: > 329 (category support): fixed, we use the official implementation from the > trunk > 786 (@Category with forkMode=always): fixed, we use the official > implementation from the trunk > 791 (incorrect elapsed time on test failure): fixed, we use the official > implementation from the trunk > 793 (incorrect time in the XML report): Not fixed (reopen) on trunk, fixed on > our version. > 760 (does not take into account the test method): fixed in trunk, not fixed > in our version > 798 (print immediately the test class name): not fixed in trunk, not fixed in > our version > 799 (Allow test parallelization when forkMode=always): not fixed in trunk, > not fixed in our version > 800 (redirectTestOutputToFile not taken into account): not yet fix on trunk, > fixed on our version > 800 & 793 are the more important to monitor, it's the only ones that are > fixed in our version but not on trunk. -- This message is automatically generated by JIRA. If 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-4955) Use the official versions of surefire & junit
[ https://issues.apache.org/jira/browse/HBASE-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-4955: --- Attachment: 4955.v2.patch > Use the official versions of surefire & junit > - > > Key: HBASE-4955 > URL: https://issues.apache.org/jira/browse/HBASE-4955 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Fix For: 0.95.0 > > Attachments: 4955.v1.patch, 4955.v2.patch, 4955.v2.patch, > 4955.v2.patch > > > We currently use private versions for Surefire & JUnit since HBASE-4763. > This JIRA traks what we need to move to official versions. > Surefire 2.11 is just out, but, after some tests, it does not contain all > what we need. > JUnit. Could be for JUnit 4.11. Issue to monitor: > https://github.com/KentBeck/junit/issues/359: fixed in our version, no > feedback for an integration on trunk > Surefire: Could be for Surefire 2.12. Issues to monitor are: > 329 (category support): fixed, we use the official implementation from the > trunk > 786 (@Category with forkMode=always): fixed, we use the official > implementation from the trunk > 791 (incorrect elapsed time on test failure): fixed, we use the official > implementation from the trunk > 793 (incorrect time in the XML report): Not fixed (reopen) on trunk, fixed on > our version. > 760 (does not take into account the test method): fixed in trunk, not fixed > in our version > 798 (print immediately the test class name): not fixed in trunk, not fixed in > our version > 799 (Allow test parallelization when forkMode=always): not fixed in trunk, > not fixed in our version > 800 (redirectTestOutputToFile not taken into account): not yet fix on trunk, > fixed on our version > 800 & 793 are the more important to monitor, it's the only ones that are > fixed in our version but not on trunk. -- This message is automatically generated by JIRA. If 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-4955) Use the official versions of surefire & junit
[ https://issues.apache.org/jira/browse/HBASE-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-4955: --- Fix Version/s: (was: 0.95.0) 0.96.0 Status: Patch Available (was: Open) > Use the official versions of surefire & junit > - > > Key: HBASE-4955 > URL: https://issues.apache.org/jira/browse/HBASE-4955 > Project: HBase > Issue Type: Improvement > Components: test >Affects Versions: 0.94.0 > Environment: all >Reporter: nkeywal >Assignee: nkeywal >Priority: Minor > Fix For: 0.96.0 > > Attachments: 4955.v1.patch, 4955.v2.patch, 4955.v2.patch, > 4955.v2.patch > > > We currently use private versions for Surefire & JUnit since HBASE-4763. > This JIRA traks what we need to move to official versions. > Surefire 2.11 is just out, but, after some tests, it does not contain all > what we need. > JUnit. Could be for JUnit 4.11. Issue to monitor: > https://github.com/KentBeck/junit/issues/359: fixed in our version, no > feedback for an integration on trunk > Surefire: Could be for Surefire 2.12. Issues to monitor are: > 329 (category support): fixed, we use the official implementation from the > trunk > 786 (@Category with forkMode=always): fixed, we use the official > implementation from the trunk > 791 (incorrect elapsed time on test failure): fixed, we use the official > implementation from the trunk > 793 (incorrect time in the XML report): Not fixed (reopen) on trunk, fixed on > our version. > 760 (does not take into account the test method): fixed in trunk, not fixed > in our version > 798 (print immediately the test class name): not fixed in trunk, not fixed in > our version > 799 (Allow test parallelization when forkMode=always): not fixed in trunk, > not fixed in our version > 800 (redirectTestOutputToFile not taken into account): not yet fix on trunk, > fixed on our version > 800 & 793 are the more important to monitor, it's the only ones that are > fixed in our version but not on trunk. -- This message is automatically generated by JIRA. If 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-4955) Use the official versions of surefire & junit
[
https://issues.apache.org/jira/browse/HBASE-4955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604223#comment-13604223
]
Hadoop QA commented on HBASE-4955:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12574003/4955.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 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces lines longer than
100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.client.TestHTableMultiplexer
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4848//console
This message is automatically generated.
> Use the official versions of surefire & junit
> -
>
> Key: HBASE-4955
> URL: https://issues.apache.org/jira/browse/HBASE-4955
> Project: HBase
> Issue Type: Improvement
> Components: test
>Affects Versions: 0.94.0
> Environment: all
>Reporter: nkeywal
>Assignee: nkeywal
>Priority: Minor
> Fix For: 0.96.0
>
> Attachments: 4955.v1.patch, 4955.v2.patch, 4955.v2.patch,
> 4955.v2.patch
>
>
> We currently use private versions for Surefire & JUnit since HBASE-4763.
> This JIRA traks what we need to move to official versions.
> Surefire 2.11 is just out, but, after some tests, it does not contain all
> what we need.
> JUnit. Could be for JUnit 4.11. Issue to monitor:
> https://github.com/KentBeck/junit/issues/359: fixed in our version, no
> feedback for an integration on trunk
> Surefire: Could be for Surefire 2.12. Issues to monitor are:
> 329 (category support): fixed, we use the official implementation from the
> trunk
> 786 (@Category with forkMode=always): fixed, we use the official
> implementation from the trunk
> 791 (incorrect elapsed time on test failure): fixed, we use the official
> implementation from the trunk
> 793 (incorrect time in the XML report): Not fixed (reopen) on trunk, fixed on
> our version.
> 760 (does not take into account the test method): fixed in trunk, not fixed
> in our version
> 798 (print immediately the test class name): not fixed in trunk, not fixed in
> our version
> 799 (Allow test parallelization when forkMode=always): not fixed in trunk,
> not fixed in our version
> 800 (redirectTestOutputToFile not taken into account): not yet fix on trunk,
> fixed on our version
> 800 & 793 are the more important to monitor, it's the only ones that are
> fixed in our version but not on trunk.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JI
[jira] [Commented] (HBASE-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604276#comment-13604276 ] Hudson commented on HBASE-8106: --- Integrated in HBase-0.94 #906 (See [https://builds.apache.org/job/HBase-0.94/906/]) HBASE-8106 Test to check replication log znodes move is done correctly (Himanshu) (Revision 1457215) Result = SUCCESS tedyu : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-7809) Refactor Split/Merge to use HRegionFileSystem
[ https://issues.apache.org/jira/browse/HBASE-7809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matteo Bertozzi updated HBASE-7809: --- Resolution: Fixed Fix Version/s: 0.98.0 Status: Resolved (was: Patch Available) > Refactor Split/Merge to use HRegionFileSystem > - > > Key: HBASE-7809 > URL: https://issues.apache.org/jira/browse/HBASE-7809 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Minor > Fix For: 0.98.0 > > Attachments: HBASE-7809-v0.patch, HBASE-7809-v1.patch, > HBASE-7809-v2.patch, HBASE-7809-v3.patch, HBASE-7809-v4.patch > > > Use the HRegionFileSystem for the fs operations. -- This message is automatically generated by JIRA. If 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-7801) Allow a deferred sync option per Mutation.
[ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604297#comment-13604297 ] Lars Hofhansl commented on HBASE-7801: -- Of course. Will also look at the long line complaint. > Allow a deferred sync option per Mutation. > -- > > Key: HBASE-7801 > URL: https://issues.apache.org/jira/browse/HBASE-7801 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.95.0, 0.94.6 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, > 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, > 7801-0.96-v1.txt > > > Won't have time for parent. But a deferred sync option on a per operation > basis comes up quite frequently. > In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a > special mutation attribute. > For batch operation we'd take the safest sync option of any of the mutations. > I.e. if there is at least one that wants to be flushed we'd sync the batch, > if there's none of those but at least one that wants deferred flush we defer > flush the batch, 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-8097) MetaServerShutdownHandler may potentially keep bumping up DeadServer.numProcessing
[
https://issues.apache.org/jira/browse/HBASE-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604319#comment-13604319
]
Ted Yu commented on HBASE-8097:
---
nit:
{code}
+// Assign meta if we were carrying them.
{code}
them -> it
> MetaServerShutdownHandler may potentially keep bumping up
> DeadServer.numProcessing
> --
>
> Key: HBASE-8097
> URL: https://issues.apache.org/jira/browse/HBASE-8097
> Project: HBase
> Issue Type: Bug
>Reporter: Jeffrey Zhong
>Assignee: Jeffrey Zhong
> Fix For: 0.96.0
>
> Attachments: 8097.txt, hbase-8097_1.patch, hbase-8097_v2.patch
>
>
> {code}
> } catch (IOException ioe) {
> this.services.getExecutorService().submit(this);
> this.deadServers.add(serverName);
> throw new IOException("failed log splitting for " +
> serverName + ", will retry", ioe);
> }
> {code}
> this.deadServers.add(serverName); will keep incrementing
> DeadServer.numProcessing
> We can't get rid of numProcessing by just checking deadServers.size() because
> deadServers is also used to report some historically failed RSs.
--
This message is automatically generated by JIRA.
If 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-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604321#comment-13604321 ] Hudson commented on HBASE-8106: --- Integrated in hbase-0.95 #78 (See [https://builds.apache.org/job/hbase-0.95/78/]) HBASE-8106 Test to check replication log znodes move is done correctly (Himanshu) (Revision 1457217) Result = FAILURE tedyu : Files : * /hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-7824) Improve master start up time when there is log splitting work
[ https://issues.apache.org/jira/browse/HBASE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604365#comment-13604365 ] ramkrishna.s.vasudevan commented on HBASE-7824: --- Found some reasons..will keep you updated. Let me understand Jeff's patch also and the idea behind it. > Improve master start up time when there is log splitting work > - > > Key: HBASE-7824 > URL: https://issues.apache.org/jira/browse/HBASE-7824 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong > Attachments: HBASE-7824_3.patch, hbase-7824.patch, > hbase-7824_v2.patch, hbase-7824_v3.patch > > > When there is log split work going on, master start up waits till all log > split work completes even though the log split has nothing to do with meta > region servers. > It's a bad behavior considering a master node can run when log split is > happening while its start up is blocking by log split work. > Since master is kind of single point of failure, we should start it ASAP. -- This message is automatically generated by JIRA. If 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-8118) TestTablePermission depends on the execution order
[
https://issues.apache.org/jira/browse/HBASE-8118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604397#comment-13604397
]
Hudson commented on HBASE-8118:
---
Integrated in HBase-0.94-security #125 (See
[https://builds.apache.org/job/HBase-0.94-security/125/])
HBASE-8118 TestTablePermission depends on the execution order (Revision
1456951)
Result = FAILURE
mbertozzi :
Files :
*
/hbase/branches/0.94/security/src/test/java/org/apache/hadoop/hbase/security/access/TestTablePermissions.java
> TestTablePermission depends on the execution order
> --
>
> Key: HBASE-8118
> URL: https://issues.apache.org/jira/browse/HBASE-8118
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 0.95.0, 0.94.5
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Fix For: 0.94.5, 0.94.7
>
> Attachments: HBASE-8118-v0.patch
>
>
> All the tests changes the _acl_ table but they don't clear the state.
> If testGlobalPermission() runs before testBasicWrite() you end up with
> {code}
> java.lang.AssertionError: Full permission map should have entries for both
> test tables expected:<2> but was:<3>
> 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.apache.hadoop.hbase.security.access.TestTablePermissions.testBasicWrite(TestTablePermissions.java:181)
> {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-8106) Test to check replication log znodes move is done correctly
[ https://issues.apache.org/jira/browse/HBASE-8106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604398#comment-13604398 ] Hudson commented on HBASE-8106: --- Integrated in HBase-0.94-security #125 (See [https://builds.apache.org/job/HBase-0.94-security/125/]) HBASE-8106 Test to check replication log znodes move is done correctly (Himanshu) (Revision 1457215) Result = FAILURE tedyu : Files : * /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/replication/regionserver/TestReplicationSourceManager.java > Test to check replication log znodes move is done correctly > --- > > Key: HBASE-8106 > URL: https://issues.apache.org/jira/browse/HBASE-8106 > Project: HBase > Issue Type: Test > Components: Replication >Affects Versions: 0.94.5 >Reporter: Himanshu Vashishtha >Assignee: Himanshu Vashishtha > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 8106.94, 8106-rep-test-trunk-v2.patch, > HBase-8106-trunk.patch > > > ReplicationZookeeper#copyQueuesFromRSUsingMulti moves the znodes under a > regionserver failover environment. This jira is to add that the move is done > correctly. -- This message is automatically generated by JIRA. If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matteo Bertozzi updated HBASE-8067:
---
Attachment: HBASE-8067-v0.patch
the cleaner shouldn't be run during this test, since we want to manually delete
the files and verify them.
(I thought I saw the "stop the cleaner" line time ago on this test... maybe not)
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-8127) Region of a disabling or disabled table could be stucked in transition state when RS dies during Master initialization
Jeffrey Zhong created HBASE-8127:
Summary: Region of a disabling or disabled table could be stucked
in transition state when RS dies during Master initialization
Key: HBASE-8127
URL: https://issues.apache.org/jira/browse/HBASE-8127
Project: HBase
Issue Type: Bug
Affects Versions: 0.94.5
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
The issue happens when a RS dies during a master starts up. After the RS
reports open to the new master instance and dies immediately thereafter, the
RITs of disabling tables(or disabled table) on the died RS will be in RIT state
forever.
I attached a patch to simulate the situation and you can run the following
command to reproduce the issue:
{code}mvn test -PlocalTests
-Dtest=TestMasterFailover#testMasterFailoverWithMockedRITOnDeadRS{code}
Basically, we skip regions of a dead server inside
AM.processDeadServersAndRecoverLostRegions as the following code and relies on
SSH to process those skipped regions:
{code}
for (Pair deadRegion : deadServer.getValue()) {
nodes.remove(deadRegion.getFirst().getEncodedName());
}
{code}
While in SSH, we skip regions of disabling(or disabled table) again by function
processDeadRegion. Finally comes to the issue that RITs of disabling(or
disabled table) stuck there forever.
--
This message is automatically generated by JIRA.
If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604449#comment-13604449
]
stack commented on HBASE-8067:
--
+1 Matteo. Thanks for fixing. Its been broke for a good while now.
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-8067:
-
Status: Patch Available (was: Open)
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-8127) Region of a disabling or disabled table could be stucked in transition state when RS dies during Master initialization
[
https://issues.apache.org/jira/browse/HBASE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-8127:
-
Attachment: reproduce-hang.patch
After applying the patch, run a clean build and then the following command:
{code}
mvn test -PlocalTests
-Dtest=TestMasterFailover#testMasterFailoverWithMockedRITOnDeadRS
{code}
You should be able to see the following error:
{code}
test timed out after 18 milliseconds
{code}
> Region of a disabling or disabled table could be stucked in transition state
> when RS dies during Master initialization
> --
>
> Key: HBASE-8127
> URL: https://issues.apache.org/jira/browse/HBASE-8127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.5
>Reporter: Jeffrey Zhong
>Assignee: Jeffrey Zhong
> Attachments: reproduce-hang.patch
>
>
> The issue happens when a RS dies during a master starts up. After the RS
> reports open to the new master instance and dies immediately thereafter, the
> RITs of disabling tables(or disabled table) on the died RS will be in RIT
> state forever.
> I attached a patch to simulate the situation and you can run the following
> command to reproduce the issue:
> {code}mvn test -PlocalTests
> -Dtest=TestMasterFailover#testMasterFailoverWithMockedRITOnDeadRS{code}
> Basically, we skip regions of a dead server inside
> AM.processDeadServersAndRecoverLostRegions as the following code and relies
> on SSH to process those skipped regions:
> {code}
> for (Pair deadRegion : deadServer.getValue()) {
> nodes.remove(deadRegion.getFirst().getEncodedName());
> }
> {code}
> While in SSH, we skip regions of disabling(or disabled table) again by
> function processDeadRegion. Finally comes to the issue that RITs of
> disabling(or disabled table) stuck there forever.
>
--
This message is automatically generated by JIRA.
If 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-7679) implement store file management for stripe compactions
[ https://issues.apache.org/jira/browse/HBASE-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604452#comment-13604452 ] stack commented on HBASE-7679: -- bq. All patches (HBASE-7679 HBASE-7680 HBASE-7967 HBASE-8000) together, or separately? My plan was to commit separately to trunk only for now Separate if possible; too hard for little minds like mind keeping it all in my head. Let me get you a review > implement store file management for stripe compactions > -- > > Key: HBASE-7679 > URL: https://issues.apache.org/jira/browse/HBASE-7679 > Project: HBase > Issue Type: Sub-task >Reporter: Sergey Shelukhin >Assignee: Sergey Shelukhin > Attachments: HBASE-7667-and-7603-v0-incomplete.patch, > HBASE-7667-and-7603-v0-incomplete.patch, HBASE-7667-and-7603-v1.patch, > HBASE-7667-and-7603-v1.patch, HBASE-7667-v1.patch, HBASE-7667-v1.patch, > HBASE-7667-v2.patch, HBASE-7667-v2.patch, HBASE-7667-v3.patch, > HBASE-7679-v4.patch, HBASE-7679-v5.patch, HBASE-7679-v6.patch, > HBASE-7679-v7-.patch, HBASE-7679-v7.patch, HBASE-7679-v8.patch, > HBASE-7679-v9.patch > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8125) hbase-7435 broke upgrade from 0.94.2. 0.94.3 on hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-8125:
--
Attachment: 8125-0.94.txt
Patch using the described approach.
> hbase-7435 broke upgrade from 0.94.2. 0.94.3 on hadoop < 1.0.x
> --
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (HBASE-8125) hbase-7435 broke upgrade from 0.94.2. 0.94.3 on hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-8125:
-
Assignee: Ted Yu
> hbase-7435 broke upgrade from 0.94.2. 0.94.3 on hadoop < 1.0.x
> --
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 broke upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-8125:
--
Summary: HBASE-7435 broke upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop <
1.0.x (was: hbase-7435 broke upgrade from 0.94.2. 0.94.3 on hadoop < 1.0.x)
> HBASE-7435 broke upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop < 1.0.x
>
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8127) Region of a disabling or disabled table could be stucked in transition state when RS dies during Master initialization
[
https://issues.apache.org/jira/browse/HBASE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated HBASE-8127:
-
Attachment: hbase-8127_v1.patch
The fix is to remove the RIT regions skipping parts becasue the later of
function processDeadServersAndRecoverLostRegions can set internal
AM.regionsInTransition correctly and SSH is able to handle RITs of a dead
server.
I haven't run full test suit yet, just propose a fix for reviewing.
Thanks,
-Jeffrey
> Region of a disabling or disabled table could be stucked in transition state
> when RS dies during Master initialization
> --
>
> Key: HBASE-8127
> URL: https://issues.apache.org/jira/browse/HBASE-8127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.5
>Reporter: Jeffrey Zhong
>Assignee: Jeffrey Zhong
> Attachments: hbase-8127_v1.patch, reproduce-hang.patch
>
>
> The issue happens when a RS dies during a master starts up. After the RS
> reports open to the new master instance and dies immediately thereafter, the
> RITs of disabling tables(or disabled table) on the died RS will be in RIT
> state forever.
> I attached a patch to simulate the situation and you can run the following
> command to reproduce the issue:
> {code}mvn test -PlocalTests
> -Dtest=TestMasterFailover#testMasterFailoverWithMockedRITOnDeadRS{code}
> Basically, we skip regions of a dead server inside
> AM.processDeadServersAndRecoverLostRegions as the following code and relies
> on SSH to process those skipped regions:
> {code}
> for (Pair deadRegion : deadServer.getValue()) {
> nodes.remove(deadRegion.getFirst().getEncodedName());
> }
> {code}
> While in SSH, we skip regions of disabling(or disabled table) again by
> function processDeadRegion. Finally comes to the issue that RITs of
> disabling(or disabled table) stuck there forever.
>
--
This message is automatically generated by JIRA.
If 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-7824) Improve master start up time when there is log splitting work
[ https://issues.apache.org/jira/browse/HBASE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604457#comment-13604457 ] Jeffrey Zhong commented on HBASE-7824: -- [~ram_krish] Thanks for looking this as well! > Improve master start up time when there is log splitting work > - > > Key: HBASE-7824 > URL: https://issues.apache.org/jira/browse/HBASE-7824 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong > Attachments: HBASE-7824_3.patch, hbase-7824.patch, > hbase-7824_v2.patch, hbase-7824_v3.patch > > > When there is log split work going on, master start up waits till all log > split work completes even though the log split has nothing to do with meta > region servers. > It's a bad behavior considering a master node can run when log split is > happening while its start up is blocking by log split work. > Since master is kind of single point of failure, we should start it ASAP. -- This message is automatically generated by JIRA. If 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-7824) Improve master start up time when there is log splitting work
[ https://issues.apache.org/jira/browse/HBASE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604458#comment-13604458 ] Jeffrey Zhong commented on HBASE-7824: -- I think the test case fails before with the patch is due to an existing issue which I filed at https://issues.apache.org/jira/browse/HBASE-8127. Please see details there. Basically RITs of disabling(or disabled) table could stuck in RIT state forever for master failover case. The changes in the patch triggers the existing issue so we have the test failures. > Improve master start up time when there is log splitting work > - > > Key: HBASE-7824 > URL: https://issues.apache.org/jira/browse/HBASE-7824 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong > Attachments: HBASE-7824_3.patch, hbase-7824.patch, > hbase-7824_v2.patch, hbase-7824_v3.patch > > > When there is log split work going on, master start up waits till all log > split work completes even though the log split has nothing to do with meta > region servers. > It's a bad behavior considering a master node can run when log split is > happening while its start up is blocking by log split work. > Since master is kind of single point of failure, we should start it ASAP. -- This message is automatically generated by JIRA. If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604459#comment-13604459
]
Ted Yu commented on HBASE-8067:
---
Patch looks good.
Looking at CleanerChore#checkAndDelete():
{code}
for (T cleaner : cleanersChain) {
if (cleaner.isStopped() || this.stopper.isStopped()) {
LOG.warn("A file cleaner" + this.getName() + " is stopped, won't delete
any file in:"
{code}
Since this.stopper doesn't depend on the loop, I think this.stopper.isStopped()
can be lifted out of the loop.
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-8127) Region of a disabling or disabled table could be stucked in transition state when RS dies during Master initialization
[
https://issues.apache.org/jira/browse/HBASE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-8127:
-
Fix Version/s: 0.94.7
> Region of a disabling or disabled table could be stucked in transition state
> when RS dies during Master initialization
> --
>
> Key: HBASE-8127
> URL: https://issues.apache.org/jira/browse/HBASE-8127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.5
>Reporter: Jeffrey Zhong
>Assignee: Jeffrey Zhong
> Fix For: 0.94.7
>
> Attachments: hbase-8127_v1.patch, reproduce-hang.patch
>
>
> The issue happens when a RS dies during a master starts up. After the RS
> reports open to the new master instance and dies immediately thereafter, the
> RITs of disabling tables(or disabled table) on the died RS will be in RIT
> state forever.
> I attached a patch to simulate the situation and you can run the following
> command to reproduce the issue:
> {code}mvn test -PlocalTests
> -Dtest=TestMasterFailover#testMasterFailoverWithMockedRITOnDeadRS{code}
> Basically, we skip regions of a dead server inside
> AM.processDeadServersAndRecoverLostRegions as the following code and relies
> on SSH to process those skipped regions:
> {code}
> for (Pair deadRegion : deadServer.getValue()) {
> nodes.remove(deadRegion.getFirst().getEncodedName());
> }
> {code}
> While in SSH, we skip regions of disabling(or disabled table) again by
> function processDeadRegion. Finally comes to the issue that RITs of
> disabling(or disabled table) stuck there forever.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (HBASE-7824) Improve master start up time when there is log splitting work
[ https://issues.apache.org/jira/browse/HBASE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl reopened HBASE-7824: -- > Improve master start up time when there is log splitting work > - > > Key: HBASE-7824 > URL: https://issues.apache.org/jira/browse/HBASE-7824 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong > Attachments: HBASE-7824_3.patch, hbase-7824.patch, > hbase-7824_v2.patch, hbase-7824_v3.patch > > > When there is log split work going on, master start up waits till all log > split work completes even though the log split has nothing to do with meta > region servers. > It's a bad behavior considering a master node can run when log split is > happening while its start up is blocking by log split work. > Since master is kind of single point of failure, we should start it ASAP. -- This message is automatically generated by JIRA. If 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-7824) Improve master start up time when there is log splitting work
[ https://issues.apache.org/jira/browse/HBASE-7824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7824: - Fix Version/s: 0.94.7 > Improve master start up time when there is log splitting work > - > > Key: HBASE-7824 > URL: https://issues.apache.org/jira/browse/HBASE-7824 > Project: HBase > Issue Type: Bug > Components: master >Reporter: Jeffrey Zhong >Assignee: Jeffrey Zhong > Fix For: 0.94.7 > > Attachments: HBASE-7824_3.patch, hbase-7824.patch, > hbase-7824_v2.patch, hbase-7824_v3.patch > > > When there is log split work going on, master start up waits till all log > split work completes even though the log split has nothing to do with meta > region servers. > It's a bad behavior considering a master node can run when log split is > happening while its start up is blocking by log split work. > Since master is kind of single point of failure, we should start it ASAP. -- This message is automatically generated by JIRA. If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604462#comment-13604462
]
Hadoop QA commented on HBASE-8067:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12574021/HBASE-8067-v0.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 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4849//console
This message is automatically generated.
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-7801) Allow a deferred sync option per Mutation.
[ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-7801: - Attachment: 7801-0.96-full-v5.txt Should address javadoc and line length warning. > Allow a deferred sync option per Mutation. > -- > > Key: HBASE-7801 > URL: https://issues.apache.org/jira/browse/HBASE-7801 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.95.0, 0.94.6 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, > 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, > 7801-0.96-full-v5.txt, 7801-0.96-v1.txt > > > Won't have time for parent. But a deferred sync option on a per operation > basis comes up quite frequently. > In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a > special mutation attribute. > For batch operation we'd take the safest sync option of any of the mutations. > I.e. if there is at least one that wants to be flushed we'd sync the batch, > if there's none of those but at least one that wants deferred flush we defer > flush the batch, 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604470#comment-13604470
]
Lars Hofhansl commented on HBASE-8067:
--
Is that a trunk issue only?
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 broke upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-8125:
-
Fix Version/s: 0.94.7
> HBASE-7435 broke upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop < 1.0.x
>
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 broke upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604471#comment-13604471
]
Lars Hofhansl commented on HBASE-8125:
--
+1
So this breaks 0.94 on Hadoop 0.20.x. Should I sink the RC, again?
> HBASE-7435 broke upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop < 1.0.x
>
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-7679) implement store file management for stripe compactions
[
https://issues.apache.org/jira/browse/HBASE-7679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604472#comment-13604472
]
stack commented on HBASE-7679:
--
ConcatenatedLists should have unit test.
Should this define be in the Interface or do you think it implementation
specific?
+ public static final String BLOCKING_STOREFILES_KEY =
"hbase.hstore.blockingStoreFiles";
This has to be public?
+ public byte[] getMetadataValue(byte[] key) {
On StripeStoreFileManager, do we know if this approach has merit? Have we run
models or actual test runs and can see it saves i/o? Would be interesting to
know. Do we have to commit it to figure this out? I can see committing all
the refactorings which allow different compaction policies but would think a
compaction engine would need to have proven merit before it goes in? What you
think Sergey?
Do we have to have a L0? Can we not flush multiple files when we flush, one
per boundary in the region? Was that thought just too much work flushing?
> implement store file management for stripe compactions
> --
>
> Key: HBASE-7679
> URL: https://issues.apache.org/jira/browse/HBASE-7679
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sergey Shelukhin
>Assignee: Sergey Shelukhin
> Attachments: HBASE-7667-and-7603-v0-incomplete.patch,
> HBASE-7667-and-7603-v0-incomplete.patch, HBASE-7667-and-7603-v1.patch,
> HBASE-7667-and-7603-v1.patch, HBASE-7667-v1.patch, HBASE-7667-v1.patch,
> HBASE-7667-v2.patch, HBASE-7667-v2.patch, HBASE-7667-v3.patch,
> HBASE-7679-v4.patch, HBASE-7679-v5.patch, HBASE-7679-v6.patch,
> HBASE-7679-v7-.patch, HBASE-7679-v7.patch, HBASE-7679-v8.patch,
> HBASE-7679-v9.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-8125) HBASE-7435 break BuildGzip hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-8125:
-
Summary: HBASE-7435 break BuildGzip hadoop < 1.0.x (was: HBASE-7435 broke
upgrade from 0.94.2, 0.94.3 to 0.94.4 on hadoop < 1.0.x)
> HBASE-7435 break BuildGzip hadoop < 1.0.x
> -
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated HBASE-8125:
-
Summary: HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x (was:
HBASE-7435 break BuildGzip hadoop < 1.0.x)
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604473#comment-13604473
]
Ted Yu commented on HBASE-8125:
---
This happened at the release of 0.94.4
I don't think we should sink RC2.
Will report back with test suite result.
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604474#comment-13604474
]
Ted Yu commented on HBASE-8067:
---
@Lars:
If you were talking about the code snippet I mentioned, the issue is in 0.94 as
well.
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-7801) Allow a deferred sync option per Mutation.
[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604476#comment-13604476
]
Hadoop QA commented on HBASE-7801:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12574030/7801-0.96-full-v5.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 153
new or modified tests.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces lines longer than
100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4850//console
This message is automatically generated.
> Allow a deferred sync option per Mutation.
> --
>
> Key: HBASE-7801
> URL: https://issues.apache.org/jira/browse/HBASE-7801
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 0.95.0, 0.94.6
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt,
> 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt,
> 7801-0.96-full-v5.txt, 7801-0.96-v1.txt
>
>
> Won't have time for parent. But a deferred sync option on a per operation
> basis comes up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a
> special mutation attribute.
> For batch operation we'd take the safest sync option of any of the mutations.
> I.e. if there is at least one that wants to be flushed we'd sync the batch,
> if there's none of those but at least one that wants deferred flush we defer
> flush the batch, 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-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604478#comment-13604478
]
Jean-Marc Spaggiari commented on HBASE-8125:
I agree with Ted.
If it was already failing in previous releases, I don't think this should sunk
this current RC.
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604480#comment-13604480
]
Hudson commented on HBASE-8067:
---
Integrated in hbase-0.95 #79 (See
[https://builds.apache.org/job/hbase-0.95/79/])
HBASE-8067 TestHFileArchiving.testArchiveOnTableDelete sometimes fails
(Revision 1457346)
Result = FAILURE
mbertozzi :
Files :
*
/hbase/branches/0.95/hbase-server/src/test/java/org/apache/hadoop/hbase/backup/TestHFileArchiving.java
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-8001) Avoid unnecessary lazy seek
[ https://issues.apache.org/jira/browse/HBASE-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604484#comment-13604484 ] Lars Hofhansl commented on HBASE-8001: -- I would really like to understand what specific scenario this is optimizing. Since you're doing an M/R job, maybe this is improving only with multiple threads? In a single threaded env with a single RS and DN only, I cannot discern any improvement from this, so it must be somewhere else. > Avoid unnecessary lazy seek > --- > > Key: HBASE-8001 > URL: https://issues.apache.org/jira/browse/HBASE-8001 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 0.94.5 >Reporter: Raymond Liu >Assignee: Raymond Liu > Fix For: 0.98.0 > > Attachments: HBASE-8001_onescanner.patch, > HBASE-8001_onescanner_v2.patch > > > Lazy seek helps to reduce the real seek needed for multi hfile, when the kv > from newer hfile is enough to satisfy the query. > While in many case, it just push the real seek later, and do not reduce the > number of real seek. e.g. there are only one hfile, or storefilescanner is > closed and only one left, or the scan need to go through all the versions, or > there are only one version of row and a sequence scan is performed. In these > case, lazy seek just bring extra overhead. -- This message is automatically generated by JIRA. If 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-8001) Avoid unnecessary lazy seek
[ https://issues.apache.org/jira/browse/HBASE-8001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604487#comment-13604487 ] Lars Hofhansl commented on HBASE-8001: -- Does this need many columns and/or column families to show an effect? > Avoid unnecessary lazy seek > --- > > Key: HBASE-8001 > URL: https://issues.apache.org/jira/browse/HBASE-8001 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 0.94.5 >Reporter: Raymond Liu >Assignee: Raymond Liu > Fix For: 0.98.0 > > Attachments: HBASE-8001_onescanner.patch, > HBASE-8001_onescanner_v2.patch > > > Lazy seek helps to reduce the real seek needed for multi hfile, when the kv > from newer hfile is enough to satisfy the query. > While in many case, it just push the real seek later, and do not reduce the > number of real seek. e.g. there are only one hfile, or storefilescanner is > closed and only one left, or the scan need to go through all the versions, or > there are only one version of row and a sequence scan is performed. In these > case, lazy seek just bring extra overhead. -- This message is automatically generated by JIRA. If 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-8067) TestHFileArchiving.testArchiveOnTableDelete sometimes fails
[
https://issues.apache.org/jira/browse/HBASE-8067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604489#comment-13604489
]
Hudson commented on HBASE-8067:
---
Integrated in HBase-TRUNK #3964 (See
[https://builds.apache.org/job/HBase-TRUNK/3964/])
HBASE-8067 TestHFileArchiving.testArchiveOnTableDelete sometimes fails
(Revision 1457345)
Result = FAILURE
mbertozzi :
Files :
*
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/backup/TestHFileArchiving.java
> TestHFileArchiving.testArchiveOnTableDelete sometimes fails
> ---
>
> Key: HBASE-8067
> URL: https://issues.apache.org/jira/browse/HBASE-8067
> Project: HBase
> Issue Type: Bug
> Components: Admin, master, test
>Affects Versions: 0.96.0, 0.94.6
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
> Attachments: HBASE-8067-debug.patch, HBASE-8067-v0.patch
>
>
> it seems that testArchiveOnTableDelete() fails because the archiving in
> DeleteTableHandler is still in progress when admin.deleteTable() returns.
> {code}
> Error Message
> Archived files are missing some of the store files!
> Stacktrace
> java.lang.AssertionError: Archived files are missing some of the store files!
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.hadoop.hbase.backup.TestHFileArchiving.testArchiveOnTableDelete(TestHFileArchiving.java:262)
> {code}
> (Looking at the problem in a more generic way, we don't have any way to
> inform the client when an async operation is completed)
--
This message is automatically generated by JIRA.
If 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-8128) HTable#put improvements
nkeywal created HBASE-8128: -- Summary: HTable#put improvements Key: HBASE-8128 URL: https://issues.apache.org/jira/browse/HBASE-8128 Project: HBase Issue Type: Bug Components: Client Affects Versions: 0.95.0, 0.96.0 Reporter: nkeywal Assignee: nkeywal Priority: Trivial Fix For: 0.95.0, 0.96.0 Attachments: 8128.v1.patch 3 points: - When doing a single put, we're creating an object by calling Arrays.asList - we're doing a size check every 10 put. Not doing it seems simpler, better and allows to share some code between a single put and a list of puts. - we could call flushCommits on empty write buffer, especially for someone using a lot of HTable instead of using a pool, as it's called in close(). -- This message is automatically generated by JIRA. If 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-8128) HTable#put improvements
[ https://issues.apache.org/jira/browse/HBASE-8128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-8128: --- Status: Patch Available (was: Open) > HTable#put improvements > --- > > Key: HBASE-8128 > URL: https://issues.apache.org/jira/browse/HBASE-8128 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.95.0, 0.96.0 >Reporter: nkeywal >Assignee: nkeywal >Priority: Trivial > Fix For: 0.95.0, 0.96.0 > > Attachments: 8128.v1.patch > > > 3 points: > - When doing a single put, we're creating an object by calling Arrays.asList > - we're doing a size check every 10 put. Not doing it seems simpler, better > and allows to share some code between a single put and a list of puts. > - we could call flushCommits on empty write buffer, especially for someone > using a lot of HTable instead of using a pool, as it's called in close(). -- This message is automatically generated by JIRA. If 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-8128) HTable#put improvements
[ https://issues.apache.org/jira/browse/HBASE-8128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated HBASE-8128: --- Attachment: 8128.v1.patch > HTable#put improvements > --- > > Key: HBASE-8128 > URL: https://issues.apache.org/jira/browse/HBASE-8128 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 0.95.0, 0.96.0 >Reporter: nkeywal >Assignee: nkeywal >Priority: Trivial > Fix For: 0.95.0, 0.96.0 > > Attachments: 8128.v1.patch > > > 3 points: > - When doing a single put, we're creating an object by calling Arrays.asList > - we're doing a size check every 10 put. Not doing it seems simpler, better > and allows to share some code between a single put and a list of puts. > - we could call flushCommits on empty write buffer, especially for someone > using a lot of HTable instead of using a pool, as it's called in close(). -- This message is automatically generated by JIRA. If 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-7801) Allow a deferred sync option per Mutation.
[ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604493#comment-13604493 ] Lars Hofhansl commented on HBASE-7801: -- Are generated filed (like ClientProtos.java) excluded from the long-line check? > Allow a deferred sync option per Mutation. > -- > > Key: HBASE-7801 > URL: https://issues.apache.org/jira/browse/HBASE-7801 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.95.0, 0.94.6 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, > 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, > 7801-0.96-full-v5.txt, 7801-0.96-v1.txt > > > Won't have time for parent. But a deferred sync option on a per operation > basis comes up quite frequently. > In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a > special mutation attribute. > For batch operation we'd take the safest sync option of any of the mutations. > I.e. if there is at least one that wants to be flushed we'd sync the batch, > if there's none of those but at least one that wants deferred flush we defer > flush the batch, 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] [Updated] (HBASE-7905) Add passing of optional cell blocks over rpc
[ https://issues.apache.org/jira/browse/HBASE-7905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-7905: - Attachment: 7905v14.txt Fix for bulk of the previous failures (flush after writing client header) > Add passing of optional cell blocks over rpc > > > Key: HBASE-7905 > URL: https://issues.apache.org/jira/browse/HBASE-7905 > Project: HBase > Issue Type: Sub-task > Components: IPC/RPC >Reporter: stack >Assignee: stack > Fix For: 0.95.0 > > Attachments: 7900v12-depends-on-8101.txt, 7905.txt, 7905v13.txt, > 7905v14.txt, 7905v3.txt, 7905v4.txt, 7905v6.txt, 7905v8.txt, 7905v9.txt > > > Make it so we can pass Cells/data w/o having to bury it all in protobuf to > get it over the wire. -- This message is automatically generated by JIRA. If 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-7801) Allow a deferred sync option per Mutation.
[
https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604496#comment-13604496
]
Ted Yu commented on HBASE-7801:
---
I don't think so:
{code}
ll=`cat $PATCH_DIR/patch | grep "^+" | grep -v "^@@" | grep -v "^+++" | grep
-v "import" | wc -L`
MAX_LINE_LENGTH_PATCH=`expr $MAX_LINE_LENGTH + 1`
if [[ "$ll" -gt "$MAX_LINE_LENGTH_PATCH" ]]; then
{code}
> Allow a deferred sync option per Mutation.
> --
>
> Key: HBASE-7801
> URL: https://issues.apache.org/jira/browse/HBASE-7801
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 0.95.0, 0.94.6
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt,
> 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt,
> 7801-0.96-full-v5.txt, 7801-0.96-v1.txt
>
>
> Won't have time for parent. But a deferred sync option on a per operation
> basis comes up quite frequently.
> In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a
> special mutation attribute.
> For batch operation we'd take the safest sync option of any of the mutations.
> I.e. if there is at least one that wants to be flushed we'd sync the batch,
> if there's none of those but at least one that wants deferred flush we defer
> flush the batch, 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] [Created] (HBASE-8129) Enhance long line detection in patch testing by ignoring generated files
Ted Yu created HBASE-8129: - Summary: Enhance long line detection in patch testing by ignoring generated files Key: HBASE-8129 URL: https://issues.apache.org/jira/browse/HBASE-8129 Project: HBase Issue Type: Bug Reporter: Ted Yu Currently test-patch.sh doesn't distinguish long line in developer written code and code in generated files (from .proto files, e.g.) We can enhance long line detection by excluding generated files. -- This message is automatically generated by JIRA. If 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-7801) Allow a deferred sync option per Mutation.
[ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604498#comment-13604498 ] Lars Hofhansl commented on HBASE-7801: -- Might be a good thing to add anyway. The long lines left that I noticed were in ClientProtos.java. I'll double check the patch. > Allow a deferred sync option per Mutation. > -- > > Key: HBASE-7801 > URL: https://issues.apache.org/jira/browse/HBASE-7801 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.95.0, 0.94.6 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, > 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, > 7801-0.96-full-v5.txt, 7801-0.96-v1.txt > > > Won't have time for parent. But a deferred sync option on a per operation > basis comes up quite frequently. > In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a > special mutation attribute. > For batch operation we'd take the safest sync option of any of the mutations. > I.e. if there is at least one that wants to be flushed we'd sync the batch, > if there's none of those but at least one that wants deferred flush we defer > flush the batch, 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-7801) Allow a deferred sync option per Mutation.
[ https://issues.apache.org/jira/browse/HBASE-7801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604499#comment-13604499 ] Ted Yu commented on HBASE-7801: --- I logged HBASE-8129 for making long line detection smarter > Allow a deferred sync option per Mutation. > -- > > Key: HBASE-7801 > URL: https://issues.apache.org/jira/browse/HBASE-7801 > Project: HBase > Issue Type: Sub-task >Affects Versions: 0.95.0, 0.94.6 >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.98.0, 0.94.7 > > Attachments: 7801-0.94-v1.txt, 7801-0.94-v2.txt, 7801-0.94-v3.txt, > 7801-0.96-full-v2.txt, 7801-0.96-full-v3.txt, 7801-0.96-full-v4.txt, > 7801-0.96-full-v5.txt, 7801-0.96-v1.txt > > > Won't have time for parent. But a deferred sync option on a per operation > basis comes up quite frequently. > In 0.96 this can be handled cleanly via protobufs and 0.94 we can have a > special mutation attribute. > For batch operation we'd take the safest sync option of any of the mutations. > I.e. if there is at least one that wants to be flushed we'd sync the batch, > if there's none of those but at least one that wants deferred flush we defer > flush the batch, 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-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604500#comment-13604500
]
Ted Yu commented on HBASE-8125:
---
Tests run: 1326, Failures: 0, Errors: 0, Skipped: 13
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:04:23.845s
[INFO] Finished at: Sun Mar 17 02:34:38 UTC 2013
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604502#comment-13604502
]
Ted Yu commented on HBASE-8125:
---
Integrated to 0.94
Thanks for the review, Lars.
This is not needed for 0.95 or higher version.
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8127) Region of a disabling or disabled table could be stuck in transition state when RS dies during Master initialization
[
https://issues.apache.org/jira/browse/HBASE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-8127:
--
Summary: Region of a disabling or disabled table could be stuck in
transition state when RS dies during Master initialization (was: Region of a
disabling or disabled table could be stucked in transition state when RS dies
during Master initialization)
> Region of a disabling or disabled table could be stuck in transition state
> when RS dies during Master initialization
>
>
> Key: HBASE-8127
> URL: https://issues.apache.org/jira/browse/HBASE-8127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.5
>Reporter: Jeffrey Zhong
>Assignee: Jeffrey Zhong
> Fix For: 0.94.7
>
> Attachments: hbase-8127_v1.patch, reproduce-hang.patch
>
>
> The issue happens when a RS dies during a master starts up. After the RS
> reports open to the new master instance and dies immediately thereafter, the
> RITs of disabling tables(or disabled table) on the died RS will be in RIT
> state forever.
> I attached a patch to simulate the situation and you can run the following
> command to reproduce the issue:
> {code}mvn test -PlocalTests
> -Dtest=TestMasterFailover#testMasterFailoverWithMockedRITOnDeadRS{code}
> Basically, we skip regions of a dead server inside
> AM.processDeadServersAndRecoverLostRegions as the following code and relies
> on SSH to process those skipped regions:
> {code}
> for (Pair deadRegion : deadServer.getValue()) {
> nodes.remove(deadRegion.getFirst().getEncodedName());
> }
> {code}
> While in SSH, we skip regions of disabling(or disabled table) again by
> function processDeadRegion. Finally comes to the issue that RITs of
> disabling(or disabled table) stuck there forever.
>
--
This message is automatically generated by JIRA.
If 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-8127) Region of a disabling or disabled table could be stuck in transition state when RS dies during Master initialization
[
https://issues.apache.org/jira/browse/HBASE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604503#comment-13604503
]
Ted Yu commented on HBASE-8127:
---
Looking at reproduce-hang.patch, can we modify TestMasterFailover so that this
scenario can be reproduced without changing master code ?
e.g. by simulating the case where the region server which died didn't carry
.META. table
> Region of a disabling or disabled table could be stuck in transition state
> when RS dies during Master initialization
>
>
> Key: HBASE-8127
> URL: https://issues.apache.org/jira/browse/HBASE-8127
> Project: HBase
> Issue Type: Bug
>Affects Versions: 0.94.5
>Reporter: Jeffrey Zhong
>Assignee: Jeffrey Zhong
> Fix For: 0.94.7
>
> Attachments: hbase-8127_v1.patch, reproduce-hang.patch
>
>
> The issue happens when a RS dies during a master starts up. After the RS
> reports open to the new master instance and dies immediately thereafter, the
> RITs of disabling tables(or disabled table) on the died RS will be in RIT
> state forever.
> I attached a patch to simulate the situation and you can run the following
> command to reproduce the issue:
> {code}mvn test -PlocalTests
> -Dtest=TestMasterFailover#testMasterFailoverWithMockedRITOnDeadRS{code}
> Basically, we skip regions of a dead server inside
> AM.processDeadServersAndRecoverLostRegions as the following code and relies
> on SSH to process those skipped regions:
> {code}
> for (Pair deadRegion : deadServer.getValue()) {
> nodes.remove(deadRegion.getFirst().getEncodedName());
> }
> {code}
> While in SSH, we skip regions of disabling(or disabled table) again by
> function processDeadRegion. Finally comes to the issue that RITs of
> disabling(or disabled table) stuck there forever.
>
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604505#comment-13604505
]
Lars Hofhansl commented on HBASE-8125:
--
Thanks Ted.
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-8128) HTable#put improvements
[
https://issues.apache.org/jira/browse/HBASE-8128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604508#comment-13604508
]
Hadoop QA commented on HBASE-8128:
--
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12574031/8128.v1.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 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/4851//console
This message is automatically generated.
> HTable#put improvements
> ---
>
> Key: HBASE-8128
> URL: https://issues.apache.org/jira/browse/HBASE-8128
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 0.95.0, 0.96.0
>Reporter: nkeywal
>Assignee: nkeywal
>Priority: Trivial
> Fix For: 0.95.0, 0.96.0
>
> Attachments: 8128.v1.patch
>
>
> 3 points:
> - When doing a single put, we're creating an object by calling Arrays.asList
> - we're doing a size check every 10 put. Not doing it seems simpler, better
> and allows to share some code between a single put and a list of puts.
> - we could call flushCommits on empty write buffer, especially for someone
> using a lot of HTable instead of using a pool, as it's called in close().
--
This message is automatically generated by JIRA.
If 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-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl resolved HBASE-8125.
--
Resolution: Fixed
Hadoop Flags: Reviewed
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-7403) Online Merge
[ https://issues.apache.org/jira/browse/HBASE-7403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chunhui shen updated HBASE-7403: Attachment: hbase-7403-trunkv24.patch > Online Merge > > > Key: HBASE-7403 > URL: https://issues.apache.org/jira/browse/HBASE-7403 > Project: HBase > Issue Type: New Feature >Affects Versions: 0.95.0 >Reporter: chunhui shen >Assignee: chunhui shen >Priority: Critical > Fix For: 0.95.0, 0.98.0 > > Attachments: 7403-trunkv5.patch, 7403-trunkv6.patch, 7403v5.diff, > 7403-v5.txt, 7403v5.txt, hbase-7403-94v1.patch, hbase-7403-trunkv10.patch, > hbase-7403-trunkv11.patch, hbase-7403-trunkv12.patch, > hbase-7403-trunkv13.patch, hbase-7403-trunkv14.patch, > hbase-7403-trunkv15.patch, hbase-7403-trunkv16.patch, > hbase-7403-trunkv19.patch, hbase-7403-trunkv1.patch, > hbase-7403-trunkv20.patch, hbase-7403-trunkv22.patch, > hbase-7403-trunkv23.patch, hbase-7403-trunkv24.patch, > hbase-7403-trunkv5.patch, hbase-7403-trunkv6.patch, hbase-7403-trunkv7.patch, > hbase-7403-trunkv8.patch, hbase-7403-trunkv9.patch, merge region.pdf > > > Support executing region merge transaction on Regionserver, similar with > split transaction > Process of merging two regions: > a.client sends RPC (dispatch merging regions) to master > b.master moves the regions together (on the same regionserver where the more > heavily loaded region resided) > c.master sends RPC (merge regions) to this regionserver > d.Regionserver executes the region merge transaction in the thread pool > e.the above b,c,d run asynchronously > Process of region merge transaction: > a.Construct a new region merge transaction. > b.prepare for the merge transaction, the transaction will be canceled if it > is unavailable, > e.g. two regions don't belong to same table; two regions are not adjacent in > a non-compulsory merge; region is closed or has reference > c.execute the transaction as the following: > /** > * Set region as in transition, set it into MERGING state. > */ > SET_MERGING_IN_ZK, > /** > * We created the temporary merge data directory. > */ > CREATED_MERGE_DIR, > /** > * Closed the merging region A. > */ > CLOSED_REGION_A, > /** > * The merging region A has been taken out of the server's online regions > list. > */ > OFFLINED_REGION_A, > /** > * Closed the merging region B. > */ > CLOSED_REGION_B, > /** > * The merging region B has been taken out of the server's online regions > list. > */ > OFFLINED_REGION_B, > /** > * Started in on creation of the merged region. > */ > STARTED_MERGED_REGION_CREATION, > /** > * Point of no return. If we got here, then transaction is not recoverable > * other than by crashing out the regionserver. > */ > PONR > d.roll back if step c throws exception > Usage: > HBaseAdmin#mergeRegions > See more details from the patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-8125) HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
[
https://issues.apache.org/jira/browse/HBASE-8125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604512#comment-13604512
]
Hudson commented on HBASE-8125:
---
Integrated in HBase-0.94 #907 (See
[https://builds.apache.org/job/HBase-0.94/907/])
HBASE-8125 HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x (Ted
Yu) (Revision 1457370)
Result = FAILURE
tedyu :
Files :
*
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x
> ---
>
> Key: HBASE-8125
> URL: https://issues.apache.org/jira/browse/HBASE-8125
> Project: HBase
> Issue Type: Bug
>Reporter: stack
>Assignee: Ted Yu
> Fix For: 0.94.7
>
> Attachments: 8125-0.94.txt
>
>
> From some friends of ours at dropbox:
> Index: src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> ===
> --- src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (revision 1425723)
> +++ src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
> (working copy)
> @@ -33,6 +33,7 @@
> import org.apache.hadoop.io.compress.CompressionOutputStream;
> import org.apache.hadoop.io.compress.Compressor;
> import org.apache.hadoop.io.compress.Decompressor;
> +import org.apache.hadoop.io.compress.DoNotPool;
> import org.apache.hadoop.io.compress.GzipCodec;
> import org.apache.hadoop.io.compress.DefaultCodec;
> import org.apache.hadoop.util.ReflectionUtils;
> @@ -308,6 +309,9 @@
> public void returnDecompressor(Decompressor decompressor) {
>if (decompressor != null) {
> CodecPool.returnDecompressor(decompressor);
> +if (decompressor.getClass().isAnnotationPresent(DoNotPool.class)) {
> + decompressor.end();
> +}
>}
> }
> breaks compatibility with hadoop-0.20.2-cdh3u2.
> +import org.apache.hadoop.io.compress.DoNotPool;
> does not exist in that version of hadoop.
--
This message is automatically generated by JIRA.
If 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-7435) BuiltInGzipDecompressor is only released during full GC
[ https://issues.apache.org/jira/browse/HBASE-7435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604513#comment-13604513 ] Hudson commented on HBASE-7435: --- Integrated in HBase-0.94 #907 (See [https://builds.apache.org/job/HBase-0.94/907/]) HBASE-8125 HBASE-7435 breaks BuiltInGzipDecompressor on Hadoop < 1.0.x (Ted Yu) (Revision 1457370) Result = FAILURE tedyu : Files : * /hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java > BuiltInGzipDecompressor is only released during full GC > --- > > Key: HBASE-7435 > URL: https://issues.apache.org/jira/browse/HBASE-7435 > Project: HBase > Issue Type: Bug >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl > Fix For: 0.95.0, 0.94.4 > > Attachments: 7435-0.94.txt, 7435-0.96.txt > > > That seems to be bug in Hadoop, actually. > BuiltInGzipDecompressor.end() needs to be called to release it's resource, > but it is not called anywhere in CodecPool. > Instead the end() is called by finalize(), which is only called during a full > gc (or never, depending on JVM). > This is only an issue in test. In real life most folks will have the native > GzipDecompressor -- This message is automatically generated by JIRA. If 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-7568) [replication] Create an interface for replication queues
[ https://issues.apache.org/jira/browse/HBASE-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Trezzo updated HBASE-7568: Fix Version/s: 0.98.0 0.96.0 0.95.0 Status: Patch Available (was: Open) Submitting patch for a qa run. > [replication] Create an interface for replication queues > > > Key: HBASE-7568 > URL: https://issues.apache.org/jira/browse/HBASE-7568 > Project: HBase > Issue Type: Sub-task > Components: Replication >Reporter: Chris Trezzo >Assignee: Chris Trezzo > Fix For: 0.95.0, 0.96.0, 0.98.0 > > Attachments: HBASE-7568.trunkv1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
