0 Replies Latest reply on Mar 9, 2005 11:35 AM by Andrew May

    MDBs with durable subscription to Topic in cluster

    Andrew May Newbie

      Hi, sorry if this has been answered before, but in searching the forums I've found plenty of related threads, but most of them have different suggestions and I'm just confused at this point.

      I am trying to cluster an application that sends events on a Topic that is listened to by a couple of MDB and potentially other clients. Both of the clients use Durable subscriptions because I want to ensure that they receive all the messages. The application is packaged as an EAR and it's other parts of the application within the EAR that are creating the messages.

      I'm using a custom configuration of JBoss 4.0.1, but I've copied the JMS configuration from the all configuration and substituted the postgres persistence manager.

      Once I start a second server in the cluster and the EAR is deployed (I'm not using farming, just putting the EAR in the deploy directory), I get this error:

      javax.jms.InvalidClientIDException: This client id 'AuditMessageBean' is already registered!

      which is what I was expecting. If I remove the durable subscription from the MDBs they deploy without error, but beans on both servers process the same message which leads to duplicated processing.

      Is there a straightforward solution to this? I've seen various suggestions that include having a HASingleton MBean that activates/deactivates the MDB, or deploying the MDB in deploy-hasingleton (which would be difficult for packaging).

      Is this something that is on a TODO list somewhere? Or will it be handled by the new messaging system that is being worked on? If there is development required, is this something that is more likely to happen if I could convince the company I work for to pay for support (which I've been trying to do for some time)?

      I'm considering not clustering JMS at all, because then messages would just be consumed by the MDB on the machine they were generated on, and the application state changes they cause are replicated via TreeCache. However that would require having different sets of tables in postgres for each server in the cluster, or modifying the tables and sql to specify a server name. Also, if I want to add remote clients of the Topics in future they would have to listen to all the servers.