Thanks for info Joern. I don't know why failed_rename() in TimeBasedRolling_STest is failing. On the other hand, montlyRollover() in TimeBasedRollingWithArchiveRemoval_STest is probably failing because we are in November and the test makes incorrect assumptions about date intervals. I am currently working to improve the logic. On 01/11/2011 11:18 PM, Joern Huxhorn wrote:
Alright, 1-2 tests fail repeatedly at the moment. The second one less often than the first one.
They didn't fail (which may have been a strange coincidence) until 1b3439a5868d50b8423f675e15dc8db9a35b7102 and kept failing for every single build since then, i.e. 10 builds.
ch.qos.logback.core.rolling.TimeBasedRolling_STest.failed_rename
Stacktrace
java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at ch.qos.logback.core.rolling.TimeBasedRolling_STest.zCheck(TimeBasedRolling_STest.scala:111) at ch.qos.logback.core.rolling.TimeBasedRolling_STest$$anonfun$failed_rename$1.apply(TimeBasedRolling_STest.scala:192) at ch.qos.logback.core.rolling.TimeBasedRolling_STest$$anonfun$failed_rename$1.apply(TimeBasedRolling_STest.scala:192) at ch.qos.logback.core.rolling.TimeBasedRolling_STest.genericTest(TimeBasedRolling_STest.scala:91) at ch.qos.logback.core.rolling.TimeBasedRolling_STest.failed_rename(TimeBasedRolling_STest.scala:192) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680)
Standard Output
target/test-output/1518562641/failed_rename.log src/test/witness/rolling/tbr-failed_renameFiles [target/test-output/1518562641/failed_rename.log] and [src/test/witness/rolling/tbr-failed_rename] differ on line 1 One reads: [Hello---2]. Other reads:[Hello---0]. -------------------------------- Contents of target/test-output/1518562641/failed_rename.log: 1 : Hello---2 -------------------------------- Contents of src/test/witness/rolling/tbr-failed_rename: 1 : Hello---0 2 : Hello---1 3 : Hello---2 22:55:08,544 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - No compression will be used 22:55:08,544 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern target/test-output/1518562641/failed_rename-%d{yyyy-MM-dd_HH_mm_ss} for the active file 22:55:08,544 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd_HH_mm_ss' from file name pattern 'target/test-output/1518562641/failed_rename-%d{yyyy-MM-dd_HH_mm_ss}'. 22:55:08,544 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over every second. 22:55:08,544 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Tue Nov 01 22:55:08 CET 2011 22:55:08,544 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - Active log file name: target/test-output/1518562641/failed_rename.log 22:55:08,544 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[null] - File property is set to [target/test-output/1518562641/failed_rename.log] 22:55:08,544 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [target/test-output/1518562641/failed_rename.log] to [target/test-output/1518562641/failed_rename-2011-11-01_22_55_08] 22:55:08,545 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [target/test-output/1518562641/failed_rename.log] to [target/test-output/1518562641/failed_rename-2011-11-01_22_55_09]
ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_STest.montlyRollover
Error Message
expected:<7> but was:<6>
Stacktrace
java.lang.AssertionError: expected:<7> but was:<6> at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.failNotEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:126) at org.junit.Assert.assertEquals(Assert.java:470) at org.junit.Assert.assertEquals(Assert.java:454) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_STest.check(TimeBasedRollingWithArchiveRemoval_STest.scala:266) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_STest.genMontlyRollover(TimeBasedRollingWithArchiveRemoval_STest.scala:64) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemoval_STest.montlyRollover(TimeBasedRollingWithArchiveRemoval_STest.scala:73) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680)
Joern.
On 29.10.2011, at 16:32, ceki wrote:
Thanks Joern. There are still occasional build errors on heavily loaded or very slow machines but they occur less often than before. I'll have another go at the build after I build up the courage.
On 29/10/2011 3:09 PM, Joern Huxhorn wrote:
Hi Ceki,
just wanted to let you know that it appears like you really fixed the build/tests now. No random build failures on our systems anymore, thumbs up.
Cheers, Joern.