You might want to ask on the hornetq forums :
The 2.2.X releases might be the last ones that work against AS 5.1.0.GA, but the people on the hornetq forum would know.
For others that may read this post, we figured out our problem. I applied the fix from v2.2.8 to v2.2.5 source and rebuilt. It turns out that was not our issue. After some profiling, it turns out that we were getting bitten by using Redelivery-Delay. We had setup throughput tests that slammed tons of messages into our system. Several queues had the delay set to a non-zero value. Since we are using Camel JMS with Spring's DefaultMessageListenerContainer under the covers, message consumers were being open/closed repeatedly, internally closing the concrete HornetQ consumer and flushing its internal message buffer. Each message was then getting marked for re-delivery, setting the scheduled delivery time on each message in the buffer. In cases where we had slow consumers, this forced messages to get backed up many times until finally the last group of messages through the system were all spaced out by a factor of the Redelivery-Delay. The other side effect of course was that all of our messages were out of order, in a system where the order of messages is a high priority. We fixed the issue by turning off redelivery-delay and setting the ConsumerWindowSize to 0. I think that we could also address the issue by caching Message consumers, but that will be a much bigger change at the moment.