This is a Broker side problem that only manifests itself when Broker is co-located with the testing framework.
Investigation shows that on the occasions that fail, the QpidBrokerTestCase#tearDown is underway whilst the QueueDeclare is being processed (the QueueDeclate is part of the client's resubscribe activity after failover).
The tearDown reverts changes to system properties. The QueueDeclare uses the Configuration object to create a QueueConfiguration for the new queue. There is an unlucky timing where thread processing the QueueDeclare can be interating the configuration keys whilst in the main thread, #tearDown is removing the test system properties. As the Configuration is formed from a composite configuration comprising config.xml + system properties, the modification to the system properties can give rise to the ConcurrentModificationException.
The underlying problem here is
QPID-3691. The client should not proceed (i.e report failover complete) until it knows the resubscribe activity is complete (i.e. synch'd).