I have traced out from JBoss Messaging the places in the JCA/MDB container code that create JMS connections to handle MDBs.

I deployed an MDB and sent a message to it from a client application.

When using JMSContainerInvoker, 3 connections were created by the AS.

1) To handle the DLQ

2) For the connection consumer

3) To create the session that is used to handle the delivery of the message

This all works happily with a non clustered JMS provider like JBoss MQ, since the connections will always be created on the same server - this is because JBoss MQ is a HA Singleton and there is only ever one active server in the cluster at any one time.

However it causes major issues for JBoss Messaging, (and probably for any other more advanced messaging provider which has many active nodes in the cluster at any one time), since subsequent connections will actually be created on different servers.

This means that connection 2) and 3) wil typically be on different servers (we round robin between servers) - which means that any messages received on 2) will get acked on 3), which wil result in the server barfing since it won't know about the messages (they came from a different server).

The new(er) JCA inflow code basically has the same problem, meaning it will only really work with single server jms providers (i.e. JBossMQ).

I can't reallyunderstand why the JCA/MDB container doesn't use the same connection for 2) and 3).

The upshot of this, is that, when using MDBs with JBoss Messaging (or probably any other modern JMS provider that has load balancing) we must turn off load-balancing.

This means that all MDBs will be creating their connections to the same server in the cluster and we will have a poor use of the cluster.

How easy would it be to fix the ConnectionConsumer / JCA inflow so it uses the same connection for 2) and 3)?

We really need MDBs to be able to take advantage of clustered JMS.