You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Himanshu Vashishtha (JIRA)" <ji...@apache.org> on 2012/09/04 19:20:07 UTC

[jira] [Created] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Himanshu Vashishtha created HBASE-6714:
------------------------------------------

             Summary: TestMultiSlaveReplication#testMultiSlaveReplication may fail
                 Key: HBASE-6714
                 URL: https://issues.apache.org/jira/browse/HBASE-6714
             Project: HBase
          Issue Type: Bug
          Components: replication, test
    Affects Versions: 0.94.0, 0.92.0
            Reporter: Himanshu Vashishtha
            Assignee: Himanshu Vashishtha


TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Himanshu Vashishtha (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460530#comment-13460530 ] 

Himanshu Vashishtha commented on HBASE-6714:
--------------------------------------------

Any comments/reviews?
                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Himanshu Vashishtha (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451159#comment-13451159 ] 

Himanshu Vashishtha commented on HBASE-6714:
--------------------------------------------

jenkins is green; looks like an unrelated failure.
                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Hadoop QA (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13451149#comment-13451149 ] 

Hadoop QA commented on HBASE-6714:
----------------------------------

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12544318/HBase-6714-v1.patch
  against trunk revision .

    +1 @author.  The patch does not contain any @author tags.

    +1 tests included.  The patch appears to include 3 new or modified tests.

    +1 hadoop2.0.  The patch compiles against the hadoop 2.0 profile.

    +1 javadoc.  The javadoc tool did not generate any warning messages.

    -1 javac.  The patch appears to cause mvn compile goal to fail.

    -1 findbugs.  The patch appears to cause Findbugs (version 1.3.9) to fail.

    +1 release audit.  The applied patch does not increase the total number of release audit warnings.

     -1 core tests.  The patch failed these unit tests:
                       org.apache.hadoop.hbase.io.hfile.TestForceCacheImportantBlocks

Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/2821//testReport/
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/2821//console

This message is automatically generated.
                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Updated] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Himanshu Vashishtha (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Himanshu Vashishtha updated HBASE-6714:
---------------------------------------

    Status: Patch Available  (was: Open)
    
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: replication, test
>    Affects Versions: 0.94.0, 0.92.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Updated] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "stack (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack updated HBASE-6714:
-------------------------

       Resolution: Fixed
    Fix Version/s: 0.96.0
                   0.94.2
     Hadoop Flags: Reviewed
           Status: Resolved  (was: Patch Available)

Committed to 0.94 and to trunk.  Thanks for the patch Himanshu.
                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>             Fix For: 0.94.2, 0.96.0
>
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460925#comment-13460925 ] 

Hudson commented on HBASE-6714:
-------------------------------

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #186 (See [https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/186/])
    HBASE-6714 TestMultiSlaveReplication#testMultiSlaveReplication may fail (Revision 1388620)

     Result = FAILURE
stack : 
Files : 
* /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestMultiSlaveReplication.java

                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>             Fix For: 0.94.2, 0.96.0
>
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469910#comment-13469910 ] 

Hudson commented on HBASE-6714:
-------------------------------

Integrated in HBase-0.94-security-on-Hadoop-23 #8 (See [https://builds.apache.org/job/HBase-0.94-security-on-Hadoop-23/8/])
    HBASE-6714 TestMultiSlaveReplication#testMultiSlaveReplication may fail (Revision 1388621)

     Result = FAILURE
stack : 
Files : 
* /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/replication/TestMultiSlaveReplication.java

                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>             Fix For: 0.94.2, 0.96.0
>
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Updated] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Himanshu Vashishtha (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Himanshu Vashishtha updated HBASE-6714:
---------------------------------------

    Attachment: HBase-6714-v1.patch

Passed locally in a loop of 15; 
enqueued jenkins.
                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460802#comment-13460802 ] 

Hudson commented on HBASE-6714:
-------------------------------

Integrated in HBase-TRUNK #3367 (See [https://builds.apache.org/job/HBase-TRUNK/3367/])
    HBASE-6714 TestMultiSlaveReplication#testMultiSlaveReplication may fail (Revision 1388620)

     Result = ABORTED
stack : 
Files : 
* /hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/replication/TestMultiSlaveReplication.java

                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>             Fix For: 0.94.2, 0.96.0
>
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Updated] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Himanshu Vashishtha (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Himanshu Vashishtha updated HBASE-6714:
---------------------------------------

    Priority: Minor  (was: Major)
    
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "stack (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460711#comment-13460711 ] 

stack commented on HBASE-6714:
------------------------------

I love patches that fix broke tests.

In future, rather than this:

{code}
+      if (i == NB_RETRIES - 1) {
+        fail("Waited too much time while getting the row.");
+      }
{code}

... just throw an exception rather than call fail?

Let me commit.
                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460832#comment-13460832 ] 

Hudson commented on HBASE-6714:
-------------------------------

Integrated in HBase-0.94-security #54 (See [https://builds.apache.org/job/HBase-0.94-security/54/])
    HBASE-6714 TestMultiSlaveReplication#testMultiSlaveReplication may fail (Revision 1388621)

     Result = ABORTED
stack : 
Files : 
* /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/replication/TestMultiSlaveReplication.java

                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>             Fix For: 0.94.2, 0.96.0
>
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Himanshu Vashishtha (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447827#comment-13447827 ] 

Himanshu Vashishtha commented on HBASE-6714:
--------------------------------------------

Since we are interested in seeing whether a row is replicated while log is rolled, we can add a method checkAndWait to see if it is replicated.
                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Commented] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Hudson (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13460803#comment-13460803 ] 

Hudson commented on HBASE-6714:
-------------------------------

Integrated in HBase-0.94 #478 (See [https://builds.apache.org/job/HBase-0.94/478/])
    HBASE-6714 TestMultiSlaveReplication#testMultiSlaveReplication may fail (Revision 1388621)

     Result = ABORTED
stack : 
Files : 
* /hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/replication/TestMultiSlaveReplication.java

                
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>            Priority: Minor
>             Fix For: 0.94.2, 0.96.0
>
>         Attachments: HBase-6714-v1.patch
>
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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

[jira] [Updated] (HBASE-6714) TestMultiSlaveReplication#testMultiSlaveReplication may fail

Posted by "Himanshu Vashishtha (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-6714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Himanshu Vashishtha updated HBASE-6714:
---------------------------------------

    Description: 
java.lang.AssertionError: expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)



TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

  was:TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

    
> TestMultiSlaveReplication#testMultiSlaveReplication may fail
> ------------------------------------------------------------
>
>                 Key: HBASE-6714
>                 URL: https://issues.apache.org/jira/browse/HBASE-6714
>             Project: HBase
>          Issue Type: Bug
>          Components: replication, test
>    Affects Versions: 0.92.0, 0.94.0
>            Reporter: Himanshu Vashishtha
>            Assignee: Himanshu Vashishtha
>
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:93)
> at org.junit.Assert.failNotEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:128)
> at org.junit.Assert.assertEquals(Assert.java:472)
> at org.junit.Assert.assertEquals(Assert.java:456)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.checkRow(TestMultiSlaveReplication.java:203)
> at org.apache.hadoop.hbase.replication.TestMultiSlaveReplication.testMultiSlaveReplication(TestMultiSlaveReplication.java:188)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> TestMultiSlaveReplication->testMultiSlaveReplication failed in our local build citing that "row" was not replicated to second peer. This is because after inserting "row", log is rolled and we look for "row2" in both the clusters and then we check for existence of "row" in both clusters. Meanwhile, Replication thread was sleeping for the second cluster and Row "row2" is not present in the second cluster from the very beginning. So, the "row2" existence check succeeds and control move on to find "row" in both clusters where it fails for the second cluster.

--
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