I just saw this fail on one of my machines, whcih isnt all that slow. The issue is that the configuration is reloaded asynchronously by starting another process to SIGHUP the broker and then immediately waiting for the log entry to appear. The configuration reload now takes longer than it used to, occasionally exceeding the timeout. Simply increasing the timeout just leaves us open to the same happening in future or even now on much slower machines. Additionally, the attached patch manipulates the static timeout variable during the test runs and so ends up altering the value for all subsequent tests as well.
There has long been a //FIXME in the associated QBTC method which performs the reload indicating that it should instead use the JMX interface to undertake the task. I have just updated it to do so, which should resolve the issue as the reload is now synchronous and the timeout should now be purely for the log file processing, as with other logging tests.