[
https://issues.apache.org/jira/browse/HBASE-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13617657#comment-13617657
]
Hadoop QA commented on HBASE-8208:
----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12576124/hbase-8208.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: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/5048//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/5048//console
This message is automatically generated.
> Data could not be replicated to slaves when deferredLogSync is enabled
> ----------------------------------------------------------------------
>
> Key: HBASE-8208
> URL: https://issues.apache.org/jira/browse/HBASE-8208
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.95.0, 0.98.0, 0.94.6
> Reporter: Jeffrey Zhong
> Assignee: Jeffrey Zhong
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
> Attachments: hbase-8208.patch
>
>
> This is a subtle issue. When deferredLogSync is enabled, there are chances we
> could flush data before syncing all HLog entries. Assuming we just flush the
> internal cache and the server dies with some unsynced hlog entries.
> Data is not lost at the source cluster while replication is based on WAL
> files and some changes we flushed at the source won't be replicated the slave
> clusters.
> Although enabling deferredLogSync with tolerances of data loss, it breaks the
> replication assumption that whatever persisted in the source should be
> replicated to its slave clusters.
> In short, the slave cluster could end up with double losses: the data loss in
> the source and some data stored in source cluster may not be replicated to
> slaves either.
> The fix of the issue isn't hard. Basically we can invoke sync during each
> flush when replication is enabled for a region server. Since sync returns
> immediately when nothing to sync so there should be no performance impact.
> Please let me know what you think!
> Thanks,
> -Jeffrey
--
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
