Just a few notes on the recent changes I made. Previously the channel itself managed the set of deliveries (i.e. refs in the process of being delivered) internally. There is an argument that this was good from the point of view of browsing (although that is contentious) since both undelivered and delivering messages can be browsed, but it created a synchronization bottleneck on a primary execution path (acknowledgment of messages) - since on acking they had to be removed from the channel, and it also introduced a set of fiddly race conditions that we've been battling with for some considerable time - i.e. messages getting acked or cancelled before the call to handle had returned making the decision of whether to add the delivery to the list more complex and requiring further expensive synchronization. The realisation was that, apart from maintaining the old queue browsing semantics there is no need to keep the deliveries in the channel. In the primary use case of delivering then acking a message, the message just needs to be removed from the queue, delivered, then when it is acked, if it is non persistent it just can be forgotten about, or if it is persistent it needs to be removed from persistent storage. Nothing in the ack process requires access to the channel if the deliveries are not store in the channel. This allows acking to proceed without any channel synchronization. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4000320#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...