hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14368) New TestWALLockup broken by addendum added to parent issue
Date Sat, 05 Sep 2015 08:11:46 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14731870#comment-14731870

Hadoop QA commented on HBASE-14368:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  against master branch at commit 2969093b5b39cb950d8710cfffa7e55484d40259.
  ATTACHMENT ID: 12754312

    {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

    {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:green}+1 core tests{color}.  The patch passed unit tests in .

     {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s): 	at org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList$Verify.run(IntegrationTestBigLinkedList.java:1103)
	at org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList$Loop.runVerify(IntegrationTestBigLinkedList.java:1259)
	at org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList$Loop.run(IntegrationTestBigLinkedList.java:1298)
	at org.apache.hadoop.hbase.test.IntegrationTestBigLinkedList.testContinuousIngest(IntegrationTestBigLinkedList.java:1584)

Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/15428//testReport/
Release Findbugs (version 2.0.3) 	warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/15428//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: https://builds.apache.org/job/PreCommit-HBASE-Build/15428//artifact/patchprocess/checkstyle-aggregate.html

  Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/15428//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, 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
> 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,
> +          // 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
> +          // 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

View raw message