[jboss-jira] [JBoss JIRA] Commented: (JBMESSAGING-1180) Provide failover for Subscriptions

Provide failover for Subscriptions ---------------------------------- Key: JBMESSAGING-1180 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1180 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Affects Versions: 1.4.0.SP2 Reporter: Jay Howell Assigned To: Tim Fox We should be able to set a switch in the TopicConnectionFactory that will allow us to configure multiple subscribers with the same clientid. Currently I see no easy way to failover if you have a subscription. Normally in a clustered situation, I would have several servers that would act as failover/loadbalanancing. For the fail over part, I would have MDBs scattered accross my cluster which would give me redundancy. If I have a durable subscriber MDB(with a specified clientid), I can only deploy that mdb on one of the nodes due to the limitations imposed by the spec. The only way to currently do this in jboss would be to deploy the mdb in the hasingleton. Then as the master went down, the mdb would fire up on the secondary. Basically the connection would abruptly end and then another server would try to establish the connection using the same client id. The problem is that we would have to wait for the connection on the serverside to timeout, before the new master could connect. If the failover happens to quickly, we could get an exception that the clientid is already registered. This work around works great for jboss serverside failover, but doesn't do much for external clients. For example, If I have a BEA cluster that wants durable subscription failover using JBM, they would have to come up with a way to host a singleton in their cluster. It would be easier to provide this with JBM. I would propose that we add a switch to the TopicConnectionFactory that relaxes this limitation set by the spec. It would allow multiple subscribers to share the same subscription with the limitation that only one of them will ever get messages. If that one connection goes down, then JBM will start publishing the messages to one of the other subscribers that share that same subscription. I encountered this in another messaging system and it seems like a way to provide better failover outside of the jboss app server. This would also simplify the clustering of durable subscriptions. A user could come up with their mdbs(with client ids defined) and could just copy the deployment to each server in the cluster, without having to take their durable subscriber mdbs and put them in HASingleton.