I can see from the test output that the test profile was the default java-mms.0-10 and as such Java Broker and Java client are co-located in the same VM.
The heuristic used by the test to calculate the number of additional threads that may remain after the test is broken. It is relying on QpidBrokerTestCase#isExternalBroker which is currently always returning true even when broker and client are co-located within the same VM. As a result, the threshold applied is half that that the author intended.
This test normally does not fail, so I suspect that you were victim of unlucky timing. I notice that the Virtual Host's housekeeping thread happened to be in progress when the test made the measurement.
I think we need to:
1) Fix QpidBrokerTestCase#isExternalBroker and the tests that use it.
2) Consider whether this is still a valuable test as the threading model used by the application is very different since the removal of Mina.
I think neither of these changes are sufficiently important to make 0-14 and should await trunk reopening. I've downgraded this Jira to Minor.