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