[jira] [Commented] (OOZIE-3533) Flaky test TestXLogService.testLog4jReload

["Andras Salamon (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OOZIE-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899935#comment-16899935 ] 

Andras Salamon commented on OOZIE-3533:
---------------------------------------

Probably it's not the reason for the flakiness, but it's definitely not a good thing that we open a {{FileInputStream}} in {{XLogService.init}} but we don't close it. Spotbugs also reports this as a problem. We should fix this in this jira.

The tests creates a configuration file but later changes it to test the reload function of log4j. Log4j checks the last modified date of the configuration file and reloads it if the date changed ( in {{FileWatchdog}} class ). The test contains a {{sleep(1 * 1000);}} line between the two file writes to enforce that the new last modified date is different than the previous one. Although I was not able to reproduce the flakiness, printing out the last modified date shows that the system does not store milliseconds, only seconds, so I think the test fails if the file modification data is the same after the second write. Probably the sleep(1000) is not accurate enough in this case.

There are several ways to fix this problem:
 # Increase the 1000 to 2000 or 3000, so the last modified date will really be different after a longer wait.
 # Check the last modified date after writing the second config file, if it's the same as before, wait for a bit and write the file again. (Put it into a loop with a timeout of 10 000ms should be enough)
 # Manually set the last modified date of the config file after writing the file to a newer value.

I'd go for option 2, but I'm open for suggestions.

> Flaky test TestXLogService.testLog4jReload
> ------------------------------------------
>
>                 Key: OOZIE-3533
>                 URL: https://issues.apache.org/jira/browse/OOZIE-3533
>             Project: Oozie
>          Issue Type: Sub-task
>    Affects Versions: trunk
>            Reporter: Andras Salamon
>            Assignee: Andras Salamon
>            Priority: Minor
>
> Sometimes this test fails with the following error message:
> {noformat}
> junit.framework.AssertionFailedError
> 	at junit.framework.Assert.fail(Assert.java:55)
> 	at junit.framework.Assert.assertTrue(Assert.java:22)
> 	at junit.framework.Assert.assertFalse(Assert.java:39)
> 	at junit.framework.Assert.assertFalse(Assert.java:47)
> 	at junit.framework.TestCase.assertFalse(TestCase.java:219)
> 	at org.apache.oozie.service.TestXLogService.testLog4jReload(TestXLogService.java:111)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at junit.framework.TestCase.runTest(TestCase.java:176)
> 	at junit.framework.TestCase.runBare(TestCase.java:141)
> 	at junit.framework.TestResult$1.protect(TestResult.java:122)
> 	at junit.framework.TestResult.runProtected(TestResult.java:142)
> 	at junit.framework.TestResult.run(TestResult.java:125)
> 	at junit.framework.TestCase.run(TestCase.java:129)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:255)
> 	at junit.framework.TestSuite.run(TestSuite.java:250)
> 	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.junit.runners.Suite.runChild(Suite.java:127)
> 	at org.junit.runners.Suite.runChild(Suite.java:26)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> 	at org.apache.maven.surefire.junitcore.pc.Scheduler$1.run(Scheduler.java:410)
> 	at org.apache.maven.surefire.junitcore.pc.InvokerStrategy.schedule(InvokerStrategy.java:54)
> 	at org.apache.maven.surefire.junitcore.pc.Scheduler.schedule(Scheduler.java:367)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 	at org.apache.maven.surefire.junitcore.pc.ParallelComputerBuilder$PC$1.run(ParallelComputerBuilder.java:593)
> 	at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
> 	at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:373)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:334)
> 	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:119)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:407)
> {noformat}
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)