[
https://issues.apache.org/jira/browse/HBASE-11135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13995972#comment-13995972
]
Hadoop QA commented on HBASE-11135:
-----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12644499/11135v6.txt
against trunk revision .
ATTACHMENT ID: 12644499
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 12 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated 5
warning messages.
{color:red}-1 findbugs{color}. The patch appears to introduce 1 new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:green}+1 site{color}. The mvn site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
org.apache.hadoop.hbase.regionserver.wal.TestLogRolling
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-thrift.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop2-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/9509//console
This message is automatically generated.
> Change region sequenceid generation so happens earlier in the append cycle
> rather than just before added to file
> ----------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-11135
> URL: https://issues.apache.org/jira/browse/HBASE-11135
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Reporter: stack
> Assignee: stack
> Attachments: 11135.wip.txt, 11135v2.txt, 11135v5.txt, 11135v5.txt,
> 11135v5.txt, 11135v6.txt
>
>
> Currently we assign the region edit/sequence id just before we put it in the
> WAL. We do it in the single thread that feeds from the ring buffer. Doing
> it at this point, we can ensure order, that the edits will be in the file in
> accordance w/ the ordering of the region sequence id.
> But the point at which region sequence id is assigned an edit is deep down in
> the WAL system and there is a lag between our putting an edit into the WAL
> system and the edit actually getting its edit/sequence id.
> This lag -- "late-binding" -- complicates the unification of mvcc and region
> sequence id, especially around async WAL writes (and, related, for no-WAL
> writes) -- the parent for this issue (For async, how you get the edit id in
> our system when the threads have all gone home -- unless you make them wait?)
> Chatting w/ Jeffrey Zhong yesterday, we came up with a crazypants means of
> getting the region sequence id near-immediately. We'll run two ringbuffers.
> The first will mesh all handler threads and the consumer will generate ids
> (we will have order on other side of this first ring buffer), and then if
> async or no sync, we will just let the threads return ... updating mvcc just
> before we let them go. All other calls will go up on to the second ring
> buffer to be serviced as now (batching, distribution out among the sync'ing
> threads). The first rb will have no friction and should turn at fast rates
> compared to the second. There should not be noticeable slowdown nor do I
> foresee this refactor intefering w/ our multi-WAL plans.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
