Announcement Announcement Module
No announcement yet.
mirrored queues Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • mirrored queues

    Good morning Dave.
    I just wanted to check with you if spring-amqp 1.0 release supports mirrored queues (


  • #2
    Spring AMQP has no explicit support for non-AMQP broker-consumer communication like consumer cancellations or publisher subscribes, but mirror queues per se are purely a broker feature so I imagine you could use them and it should be transparent to the consumer. I haven't tried it.

    P.S. it's nice to be greeted by name, but there might be others here that can answer the question, and I'd like to think they would.


    • #3
      Good evening Dave and everyone.
      I used spring-amqp 1.0.0.RELEASE and RabbitMQ 2.6.1 to test mirrored queues.
      I created a cluster with two disc nodes.
      The test queue is defined as follows:

      public Queue mdbSecQ() {
      Map<String, Object> args = new HashMap<String, Object>();
      args.put("x-ha-policy", "all");
      return new Queue(MDB_SECQ_NAME,true,false,false,args);


      CachingConnectionFactory was set with the first node hostname initially.
      After I brought down the first node where the queue is residing. I have changed the hostname set in CachingConnectionFactory to second node's host name and restarted the queue consumer and pumped in messages. Messages were successfully processed.
      This was testing the functionality of mirrored queues, therefore I didn't mind to test by changing the host name in queue configuration. We will be using HA Proxy to load balance messages in real time scenario thus there would be no manipulation of host name in connectionfactory.



      • #4
        Good afternoon.
        I have begun testing mirrored-queues functionality in a clustered environment with HA Proxy enabled.
        Using spring-amqp 1.0.0.RELEASE, RabbitMQ 2.6.1 on Linux Cent OS.
        A cluster with two RabbitMQ nodes and a node on which queue consumer is created.
        Node1: RabbitMQ: Master
        Node 2: RabbitMQ: Slave
        (When Node1 is clustered is with Node2, the queue created on Node1 or Node2 is mirrored on each other, used ha-policy as all)
        Node 3: Queue Consumer running.

        public ConnectionFactory connectionFactory() {
        CachingConnectionFactory connectionFactory = null;
        connectionFactory = new CachingConnectionFactory("ip of HA Proxy"); // HA Proxy IP is provided to route to two RabbitMQ Nodes

        return connectionFactory;

        Once everything is up and running. Brought down Node1 on which RabbitMQ is running.
        I have published a message to the queue. I could see it in the queue when I have run rabbitmqctl list_queues on Node2.
        The queue consumer got killed when the broker was brought down on Node1.
        When I tested this on Windows 7, I noticed that queue consumer was up and running even after bringing down the broker.
        Not sure why this is happening, I will investigate more on this.

        Even if the queue consumer is up and running it will not able to process any messages because the node it is tied to is down.
        Publishing messages are taken care using HA Proxy, when a request to publish message is raised, HA Proxy diverts the request to the RabbitMQ node that alive. How could I make a queue consumer High Available.
        One crude way is to have another queue consumer up and running which makes use of ConnectionFactory created from a node that is alive. But this approach duplicates writing Java Configuration and Xml Configuration for the same queue except that is provided a ConnectionFactory pointing to another node.
        Could someone suggest me better way of making the queue consumer high available.



        • #5
          I was thinking about an alternative approach which is as follows:
          Create the cluster with the following:
          - Node1 with RabbitMQ
          - Node2 with RabbitMQ
          - Node3 with queue consumers
          - Node4 with queue consumer

          Start Node3 pointing to Node1
          Start Node4 pointing to Node2
          Finally make use of HA Proxy to route messages. By doing this, if Node1 goes down thus failing Node3, Node4 should serve the purpose of HA for queue consumers.