[logback-dev] ReconfigureOnChangeTest

[Ralph Goers]

Well, I misread the code a bit. 

There are 5 threads running simultaneously all updating the same file. It appears that expectedReconfigurations is the counter from the first thread which one would assume would be 5. Since the duration of the test should be about 4.250 seconds the maximum number of reconfigurations would be 5 but is very likely to only be 4. That is still 80% and should pass.

However, I did get the test to fail one time with those settings but I have yet to repeat the failure. Since I didn't look at the test output I'm assuming that verify failed. However, I suppose it is also possible that one of the threads managed to cause a reconfiguration 6 times while the first thread only had 5 iterations.  I'll have to recreate the problem to see.

Ralph

On Dec 6, 2009, at 12:40 AM, Ralph Goers wrote:

> 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 
>