"timfox" wrote : I think the root of this problem is you are not using JBoss Messaging's transparent failover abilities but are catching exceptions yourself and recreating connections manually (which is unnecessary for JBM but necessary for other messaging systems which don't support transparent failover), and this is interacting badly with the transparent failover. If failover is transparent I would have thought there would be no exceptions to catch (in our code), unless the failover itself failed and the requested operation could not be performed by any node in the cluster. We're catching the exceptions thrown by the JMS API calls we make. Isn't it part of the JMS spec that we have to catch exceptions ourselves? The JMS API for Connection says anonymous wrote : If a JMS provider detects a serious problem with a connection it will inform the connection's ExceptionListener if one has been registered. It does this by calling the listener's onException() method passing it a JMSException describing the problem. | | This allows a client to be asynchronously notified of a problem. Some connections only consume messages so they would have no other way to learn their connection has failed. | | A Connection serializes execution of its ExceptionListener. | | A JMS provider should attempt to resolve connection problems itself prior to notifying the client of them. | What action can we realistically take if the connection exception listener tells us there is a problem? The simplest thing to do is attempt to close the connection and obtain a new one. If you're saying that we should not be recreating connections manually with JBM then our JMS code will no longer be generic - it will be tied to JBM. This is not desirable. "timfox" wrote : | This is a somewhat unusual use case but I admit it should work. I'm surprised you consider it unusual. I would have thought our main requirement is a common one: we need to be able to restart our messaging servers in a production environment independently from our web application (which is likely to be running on a separate server). When the messaging servers are stopped the messaging infrastructure in our web application must be able to disconnect. When the messaging servers are restarted our messaging infrastructure must be able to reconnect and begin processing messages again (i.e. recreate the consumers and producers). Maybe it would be easier if you showed me what the test case should look like i.e. your challenge is to write a test case that will successfully dispatch and receive messages when a JMS server is available - and continues to run when a JMS server is not available! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4026845#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...