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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira