3 Replies Latest reply on Jul 22, 2010 11:35 AM by Mike Charnoky

    HornetQ High-Availability without Multicast

    Steven Landers Newbie

      Hi there-

      We're in the cloud, and our servers do not support multicast.   We're in need of a high-availability queuing solution, and HornetQ looks fairly attractive.


      It looks like there are essentially three main approaches to failover/high-availability - and the documentation raises some concerns for us.


      1) Clustering


      "Due to a limitation in HornetQ 2.0.0, failover is not supported for clusters defined using a static set of nodes. To support failover over cluster nodes, they must be configured to use a discovery group."


      Does this mean that failover to another clustering node is impossible without multicast?

      2) Active/Passive Backup Pairs


      "Once a live server has failed over onto a backup server, the old live server becomes invalid and cannot just be restarted. To resynchonize the pair as a working live backup pair again, both servers need to be stopped, the data copied from the live node to the backup node and restarted again."


      We're not ok with having any downtime, which this seems to suggest.  It seems like we could address this if clustering allowed us to use another pair while these restarted, but again, we're not able to use multicast, and it appears that staticly-defined cluster nodes explicitly do not support failing over.

      3) Application/Client failover


      Isn't application/client failover essentially reliant on either clustering or active/passive backup pairs? 


      An alternative seems to be using JBoss HA-JNDI, but I'm not sure whether I can use HornetQ's journaling functionality across JBoss nodes (rather than HornetQ nodes).  We're also trying to avoid having to implement a highly-available shared database, as our messages are very small and extremely frequent - which isn't very replication/failover-friendly for a database.


      Am I going about this incorrectly?  The problem to solve:  we need a highly-available, failover-tolerant queuing system without using multicast/auto-discovery.


      Thoughts?  Suggestions?


      Thanks for your time-