Rabbitmq Shovel Won't Start

RabbitMQ Shovel won't start

You need to define a destination for the shovel.

    [   {mnesia, [{dump_log_write_threshold, 100}]},
        {bunny, [{vm_memory_high_watermark, 0.3}]},
        {rabbitmq_shovel,
            [{shovels,
                [{test_shovel,
                    [{sources, [{broker, "amqp://shoveluser:shoveluser@192.168.6.64:5672/"}]},
                     {destinations, [{broker, "amqp://shoveluser:shoveluser@192.168.6.66:5672/"}]},
                     {queue, >}
                    ]
                }]

            }]
        }
    ].

What happens when a shovel is deleted

Based on your latest comment, if I understand correctly, you have:

RabbitMQ1 - exchange RMQ1EXCA -> queueA1

RabbitMQ2 - exchange RMQ2EXCB -> queueB1

A shovel has been configured, exchange [RMQ1EXCA] to exchange [RMQ2EXCB]

And you found out that the queueA1 is filled up with millions of message.

If indeed this is an accurate depiction of your setup:

• it's quite normal, as queueA1 is not part of the shovel process
• if you check the queues bound to RMQ1EXCA, you should see one queue with a name starting with amq.gen-......
• deleting the shovel will not impact the queueA1, as it's not related to the process (but will delete the queue amq.gen-...... that is)

If the description provided doesn't match your setup, please provide additional information to clarify your situation so that I can adapt my answer accordingly

RabbitMQ Shovel over TLS errors with badmatch after renewing certificates

The problem turned out to be a misconfiguration of the RabbitMQ service itself. The configuration file /etc/rabbitmq/rabbitmq.config has an SSL section:

   %% Configuring SSL.
   %% See http://www.rabbitmq.com/ssl.html for full documentation.
   %%
   {ssl, [{versions, ['tlsv1.2', 'tlsv1.1']}]},
   {ssl_options, [{cacertfile,           "/etc/pki/rmq_cacert.pem"},
                  {certfile,             "/etc/pki/rmqserver/server_cert.pem"},
                  {keyfile,              "/etc/pki/rmqserver/server_key.pem"},
                  {versions,   ['tlsv1.2', 'tlsv1.1']},
                  {verify,               verify_peer},
                  {fail_if_no_peer_cert, false}]} 

Note the line for the cacertfile (/etc/pki/rmq_cacert.pem). This is the wrong location for my installation: I have a directory called rmqca for the CA certificates (following this convention, site-side my server certs go in rmqserver/, and my client certs go in rmqclient/ ). The new line is:

  {ssl_options, [{cacertfile,           "/etc/pki/rmqca/rmq_cacert.pem"},

and after a service restart all is well.

Thanks everyone for taking a look. I hope this answer helps someone else with this cryptic error message.

Can't start rabbitmq-server

{"could not start kernel pid",application_controller,"error in config file \"/etc/rabbitmq/rabbitmq.config\" (none): no ending found"}

you have invalid config no ending found

IOError: [Errno 13] Permission denied: 'src/rabbit_framing_amqp_0_9_1.erl'

you don't have a permission to write to file, run make with sudo or change destination directory

How to configure RabbitMQ bidirectional shovel and avoid infinite loop?

Seems based on the additional description you provided that:

• You are using shovel between exchanges
• Guessing that the exchange type is fanout

I can see two approaches to handle what you're trying to do:

• Use federation, and configure it in both directions between the exchanges in each cluster
• Still use shovel, but define a new queue on each exchange and configure a queue to queue shovel

For the shovel option:
You have exchange A on cluster 1, exchange A on cluster 2,
your main_queue on each cluster

• Create a secondary_queue on each cluster, bound to exchange A.
• Create a shovel from secondary queue on cluster 1 to main_queue on cluster 2
• Create a shovel from secondary queue on cluster 2 to main_queue on cluster 1

Benefit of Federation: simpler, even when you have complex routing configured

Benefit of shovel: better if you have risk of major connection disruption (more than a minute I'd say). In such cases you won't lose messages while it might happen in the Federation case that some messages don't get replicated on both clusters.

---

Related Topics