I dont think the changes in the patch will resolve the underlying test failure.
From the test we know that the 5th message has been recieved, and yet the statistcs counter still reports 4, meaning it has not yet been incremented. Synchronizing just those methods should have no effect in that scenario, as the value is retrieved via JMX and so involvs another roundtrip to the broker after the message has been received at the client. Given this, and that the occurences of this failure have only been seen on an old dual core machine, I think its likely that thread scheduling is occurring such that the delivering thread has yielded before incrementing the counter, meaning this synchronization wont help.
Adding additional synchronization on the statistics object around the message delivery and increment would also be required I believe, which isnt going to be nice for performance (and furthermore, the statistics are optional and off by default).An alternative might be to increment the counter immediatley prior to the delivery attempt, although this wasn't done previously since any exceptions thrown during delivery would make the value invalid, and reverting the increment if an exception occurs is not as simple as it sounds since it means manipulating the statistics which may have already moved on to a new reporting interval. Ick to all of the above.