Since the topic was about Spring Message Listener containers in general I thought I'd add with one gotcha that I ran into with a customer trying to integrate with JBM. If you use Spring's DefaultMessageListenerContainer, which I believe polls for new messages, ensure that you set the caching level to CACHE_NONE. The relevant comment in the Spring code is: | * Specify the level of caching that this listener container is allowed to apply. | * <p>Default is CACHE_NONE if an external transaction manager has been specified | * (to reobtain all resources freshly within the scope of the external transaction), | * and CACHE_CONSUMER else (operating with local JMS resources). | * <p>Some J2EE servers only register their JMS resources with an ongoing XA | * transaction in case of a freshly obtained JMS Connection and Session, | * which is why this listener container does by default not cache any of those. | * However, if you want to optimize for a specific server, consider switching | * this setting to at least CACHE_CONNECTION or CACHE_SESSION even in | * conjunction with an external transaction manager. | * <p>Currently known servers that absolutely require CACHE_NONE for XA | * transaction processing: JBoss 4. For any others, consider raising the | * cache level. | * @see #CACHE_NONE | * @see #CACHE_CONNECTION | * @see #CACHE_SESSION | * @see #CACHE_CONSUMER | * @see #setCacheLevelName | * @see #setTransactionManager | The way the issue ended up manifesting itself was that messages, when browsing in the JMX console, would appear stuck in a 'DELIVERING' state, even though the client had consumed them(the Session was just never closed). Sometimes this appeared to hang the queue entirely for reasons I didn't pursue further. After setting to CACHE_NONE the issue happily went away. Note that I saw this behavior with JBoss Message 1.4.0SP3 + Spring 2.5 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4171582#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...