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.
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
