[
https://issues.apache.org/jira/browse/HDFS-9904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15180154#comment-15180154
]
Kihwal Lee commented on HDFS-9904:
----------------------------------
The stack trace from the test failure.
{noformat}
java.lang.AssertionError: expected:<0> but was:<106>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:555)
at org.junit.Assert.assertEquals(Assert.java:542)
at
org.apache.hadoop.hdfs.server.namenode.ha.TestStandbyCheckpoints.testCheckpointCancellationDuringUpload(TestStandbyCheckpoints.java:328)
{noformat}
We could set DFS_NAMENODE_CHECKPOINT_TXNS_KEY differently on the first NN to
avoid it doing checkpoint when it becomes a standby.
> testCheckpointCancellationDuringUpload occasionally fails
> ----------------------------------------------------------
>
> Key: HDFS-9904
> URL: https://issues.apache.org/jira/browse/HDFS-9904
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: test
> Affects Versions: 2.7.3
> Reporter: Kihwal Lee
>
> The failure was at the end of the test case where the txid of the standby
> (former active) is checked. Since the checkpoint/uploading was canceled , it
> is not supposed to have the new checkpoint. Looking at the test log, that was
> still the case, but the standby then did checkpoint on its own and bumped up
> the txid, right before the check was performed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
