[
https://issues.apache.org/jira/browse/HBASE-14368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731701#comment-14731701
]
Hadoop QA commented on HBASE-14368:
-----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12754290/14368.txt
against master branch at commit 2969093b5b39cb950d8710cfffa7e55484d40259.
ATTACHMENT ID: 12754290
{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 hadoop versions{color}. The patch compiles with all
supported hadoop versions (2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.7.0 2.7.1)
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 protoc{color}. The applied patch does not increase the
total number of protoc compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 checkstyle{color}. The applied patch does not increase the
total number of checkstyle errors
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 2.0.3) 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 post-site goal succeeds with this patch.
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/15423//testReport/
Release Findbugs (version 2.0.3) warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/15423//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors:
https://builds.apache.org/job/PreCommit-HBASE-Build/15423//artifact/patchprocess/checkstyle-aggregate.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/15423//console
This message is automatically generated.
> New TestWALLockup broken by addendum added to parent issue
> ----------------------------------------------------------
>
> Key: HBASE-14368
> URL: https://issues.apache.org/jira/browse/HBASE-14368
> Project: HBase
> Issue Type: Sub-task
> Components: test
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0, 1.2.0, 1.0.3, 1.1.3
>
> Attachments: 14368.txt
>
>
> My second addendum broke TestWALLockup, the one that did this:
> https://issues.apache.org/jira/browse/HBASE-14317?focusedCommentId=14730301&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14730301
> {code}
> diff --git
> a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
>
> b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
> index 5708c30..c421f5c 100644
> ---
> a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
> +++
> b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/wal/FSHLog.java
> @@ -878,8 +878,19 @@ public class FSHLog implements WAL {
> // Let the writer thread go regardless, whether error or not.
> if (zigzagLatch != null) {
> zigzagLatch.releaseSafePoint();
> - // It will be null if we failed our wait on safe point above.
> - if (syncFuture != null) blockOnSync(syncFuture);
> + // syncFuture will be null if we failed our wait on safe point
> above. Otherwise, if
> + // latch was obtained successfully, the sync we threw in either
> trigger the latch or it
> + // got stamped with an exception because the WAL was damaged and
> we could not sync. Now
> + // the write pipeline has been opened up again by releasing the
> safe point, process the
> + // syncFuture we got above. This is probably a noop but it may be
> stale exception from
> + // when old WAL was in place. Catch it if so.
> + if (syncFuture != null) {
> + try {
> + blockOnSync(syncFuture);
> + } catch (IOException ioe) {
> + if (LOG.isTraceEnabled()) LOG.trace("Stale sync exception",
> ioe);
> + }
> + }
> {code}
> It broke the test because the test hand feeds appends and syncs with when
> they should throw exceptions. In the test we manufactured the case where an
> append fails and we then asserted the following sync would fail.
> Problem was that we expected the failure to be a dropped snapshot failure
> because fail of sync is a catastrophic event... but our hand feeding actually
> reproduced the case where a sync goes into the damaged file... before it had
> rolled... which is no longer a catastrophic event... we just catch and move
> on.
> The attached patch just removes check for dropped snapshot and that abort was
> called.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
