[
https://issues.apache.org/jira/browse/HBASE-10227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13869573#comment-13869573
]
Hadoop QA commented on HBASE-10227:
-----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12622605/HBASE-10227-trunk_v0.patch
against trunk revision .
ATTACHMENT ID: 12622605
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop1.1{color}. The patch compiles against the hadoop
1.1 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/8403//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/8403//console
This message is automatically generated.
> When a region is opened, its mvcc isn't correctly recovered when there are
> split hlogs to replay
> ------------------------------------------------------------------------------------------------
>
> Key: HBASE-10227
> URL: https://issues.apache.org/jira/browse/HBASE-10227
> Project: HBase
> Issue Type: Bug
> Components: regionserver
> Reporter: Feng Honghua
> Assignee: Feng Honghua
> Attachments: HBASE-10227-trunk_v0.patch
>
>
> When opening a region, all stores are examined to get the max MemstoreTS and
> it's used as the initial mvcc for the region, and then split hlogs are
> replayed. In fact the edits in split hlogs have kvs with greater mvcc than
> all MemstoreTS in all store files, but replaying them don't increment the
> mvcc according at all. From an overall perspective this mvcc recovering is
> 'logically' incorrect/incomplete.
> Why currently it doesn't incur problem is because no active scanners exists
> and no new scanners can be created before the region opening completes, so
> the mvcc of all kvs in the resulted hfiles from hlog replaying can be safely
> set to zero. They are just treated as kvs put 'earlier' than the ones in
> HFiles with mvcc greater than zero(say 'earlier' since they have mvcc less
> than the ones with non-zero mvcc, but in fact they are put 'later'), and
> without any incorrect impact just because during region opening there are no
> active scanners existing / created.
> This bug is just in 'logic' sense for the time being, but if later on we need
> to survive mvcc in the region's whole logic lifecycle(across regionservers)
> and never set them to zero, this bug needs to be fixed first.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
