Repeated runs of the JMSContainerInvokerQueueMessageDrivenUnitTestCase on my laptop (1.6GHz Pentium M) will result in the following failure:

<testcase classname="org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase" name="testRestartJMS" time="30.891">
<error message="Wrong number of messages, expected=2
got=1" type="java.lang.Exception">java.lang.Exception: Wrong
number of messages, expected=2 got=1
at org.jboss.test.messagedriven.support.CheckMessageSizeOperation.run(CheckMessageSizeOperation.java:46)
at org.jboss.test.messagedriven.support.BasicMessageDrivenUnitTest.runTest(BasicMessageDrivenUnitTest.java:112)
at org.jboss.test.messagedriven.test.JMSContainerInvokerQueueMessageDrivenUnitTestCase.testRestartJMS(JMSContainerInvokerQueueMessageDrivenUnitTestCase.java:67)

From Adrian:
The fundamental problem is waiting on a timeout for asynchronous work which will be subject to all sorts of random failures if for example you run it on your laptop while you are doing compiles or downloading e-mail.

The thread doing the wait (or the server thread doing the work) simply doesn't get scheduled in time because the cpu is busy.

The hard part is when you do a wait and you expect nothing to happen in that wait time. You don't want to slow down the testsuite doing long waits.

In general, these tests can be written better, but doing so also means testing things beyond the spec like looking at service instrumentation to check there is no outstanding work to performed before asserting state.
e.g. The jms queue is empty or a thread pool has no scheduled work, etc.