JMS2 will support this. At the moment you can't have more than one subscription.
With JMS2 you can basically not define the client-id (just the subscriptionID) and have multiple instances sharing the load.
Clebert - With the above setup, how do you then solve this problem? Do you put additional logic in the clustered MDB's to handle the consumption of the same message? Surely that'd be a hack no?
My setup is slightly different but has the same problem. My setup has 2 JAS6 nodes in a cluster that point to a (remote) standalone hornetq service for a particular MDB. However, I am unable to cluster this MDB correctly without getting the above error, i.e.:
"Cannot create a subscriber on the durable subscription since it already has subscriber(s)"
Are there any solutions or workarounds for this problem?
Did you think about using The core-api directly?
At the moment we are bound by the TCK validating this.
Clebert - Thanks for the fast response
I'm not quite sure what you mean by using the core-api directly. The MDB's are configured via Activation properties (annotations) and connection to the remote hornetq topic is configured in the ra.xml. The ra.xml is configured so that ConnectionParameters are set to the corresponding remote hornetq service. The documentation I've read thus far indicate you can use the core-api from java clients, but I'm not quite sure how to go about this via configuration and annotations...
If you could point me to an example, it would be most appreciated...
On that case you would go around MDBs. You could deploy a regular bean and do the instantiations directly