This test seems to fail consistently on my Mac. I suspect it is because the
file timestamp on some operating systems is only granular to the second and the
default interval between updates is 110 milliseconds which should result in 1
actual reconfiguration out of 10 iterations. It appears the test expects about
77% of the iterations to result in a reconfiguration so this is bound to fail.
I changed the code to check for running on a Mac -
@Before
public void setUp() {
// take into account propagation latency occurs on Linux
if (Env.isLinux() || Env.isMac()) {
sleepBetweenUpdates = 850;
totalTestDuration = sleepBetweenUpdates * 5;
} else {
totalTestDuration = sleepBetweenUpdates * 10;
}
harness = new MultiThreadedHarness(totalTestDuration);
}
but this still intermittently fails since it is easily possible to get a ratio
of less that 77% with this interval. Note that with this combination the best
that can be hoped for is that 4 out of 5 updates per thread will cause a
reconfiguration, which with 5 threads is 20 out of 25 (80%). However, if it can
be arranged that either a single iteration is delayed just a bit so that only 3
out of 5 updates result in a reconfiguration then the result would be 19 out of
25 or 76% which would result in a test failure. I am sure there are other ways
similar results could occur, but the bottom line is that this test needs a bit
more breathing room.
Ralph
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
