I'm trying to set the overflow behavior of a particular queue in the Rabbitmq to reject messages exceeding the max limit. I'm using the web console to add a new queue and set the x-max-length. Then I manually added x-overflow and gave it the value of reject-publish. But it seems the default overflow behavior is the one that is getting applied, where the older messages are removed and new ones are enqueued.
Is the way I'm defining the overflow behavior wrong? Could someone please point me how I should be setting the overflow behavior via the web console?
Its not work via web gui, only through cli.
Example:
rabbitmqctl set_policy limit-1gb ".*" '{"max-length-bytes":1000000000,"overflow":"reject-publish"}' --apply-to queues
rabbitmqctl set_policy limit-1m ".*" '{"max-length":1000000,"overflow":"reject-publish"}' --apply-to queues
The x-overflow option is only available for classic queues and NOT quorum queues. So if you were using quorum queue this is the explanation.
Currently (in Rabbit 3.8.5) the quorum queue only supports drop-head overflow, and not reject-publish or reject-publish-dlx.
Related
On windows, when I am using rabbitmq-server start/stop commands, data over the RabbitMQ durable queues are deleted. It seems queues are re-created when I start the RabbitMQ server.
If I use rabbitmqctl stop_app/start_app, I am not losing any data. Why?
What will happen if my server goes down and how can I be sure I that I won't lose data if it does?
configuration issue: I was starting rabbitmq from rabbitmq sbin directory. I re-installed the rabbitmq and added rabbitmq to windows services. Now data lost problem was solved on my computer. When I start/stop the windows service , rabbitmq is not losing any data
Making queues durable is not enough. Probably you'll need also to declare exchange as durable as well as send 'persistent' messages.
In Java you'll use:
channel.basicPublish("", "sample_queue",
MessageProperties.PERSISTENT_TEXT_PLAIN, // note that this parameter is not null!
message.getBytes())
I know the HA Policy is set by the following command:
$ rabbitmqctl set_policy ha-all "" '{"ha-mode":"all","ha-sync-mode":"automatic"}'
My question which seems basic:
Do I have to issue this command on each node or just one of them?
RabbitMQ provides to distributes the policy to all the cluster, so it does not matter which node you select the info will be distribute to the other nodes.
Please read here: https://www.rabbitmq.com/clustering.html
A RabbitMQ broker is a logical grouping of one or several Erlang
nodes, each running the RabbitMQ application and sharing users,
virtual hosts, queues, exchanges, bindings, and runtime parameters.
Sometimes we refer to the collection of nodes as a cluster.
I am new to RabbitMq. I am not able to understand the concept here. Please find the scenario.
I have two machines (RMQ1, RMQ2) where I have installed rabbitmq in both the machines which are running. Again I clustered RMQ2 to join RMQ1
cmd:/> rabbitmqctl join_cluster rabbit#RMQ1
If you see the status of the machines here it is as below
In RMQ1
c:/> rabbitmqctl cluster_status
Cluster status of node rabbit#RMQ1...
[{nodes,[{disc,[rabbit#RMQ1,rabbit#RMQ2]}]},
{running_nodes,[rabbit#RMQ1,rabbit#RMQ2]}]
In RMQ2
c:\> rabbitmqctl cluster_status
Cluster status of node rabbit#RMQ2 ...
[{nodes,[{disc,[rabbit#RMQ1,rabbit#RMQ2]}]},
{running_nodes,[rabbit#RMQ1,rabbit#RMQ2]}]
The in order to publish and subscribe message I am connecting to RMQ1. Now I see the whenever I sent or message to RMQ1, I see message mirrored in both RMQ1 and RMQ2. This I understand clearly that as both the nodes are in same cluster they are getting mirrored across nodes.
Let say I bring down the RMQ2, I still see message getting published to RMQ1.
But when I bring down the RMQ1, I cannot publish the message anymore. From this I understand that RMQ1 is master and RMQ2 is slave.
Now I have below questions, without changing the code :
How do I make the RMQ2 take up the job of accepting the message.
What is the meaning of Highly Available Queues.
How should be the strategy for implementing this kind scenario.
Please help
Question #2 is best answered first, since it will clear up a lot of things for you.
What is the meaning of highly available queues?
A good source of information for this is the Rabbit doc on high availability. It's very important to understand that mirroring (which is how you achieve high availability in Rabbit) and clustering are not the same thing. You need to create a cluster in order to mirror, but mirroring doesn't happen automatically just because you create a cluster.
When you cluster Rabbit, the nodes in the cluster share exchanges, bindings, permissions, and other resources. This allows you to manage the cluster as a single logical broker and utilize it for scenarios such as load-balancing. However, even though queues in a cluster are accessible from any machine in the cluster, each queue and its messages are still actually located only on the single node where the queue was declared.
This is why, in your case, bringing down RMQ1 will make the queues and messages unavailable. If that's the node you always connect to, then that's where those queues reside. They simply do not exist on RMQ2.
In addition, even if there are queues and messages on RMQ2, you will not be able to access them unless you specifically connect to RMQ2 after you detect that your connection to RMQ1 has been lost. Rabbit will not automatically connect you to some surviving node in a cluster.
By the way, if you look at a cluster in the RabbitMQ management console, what you see might make you think that the messages and queues are replicated. They are not. You are looking at the cluster in the management console. So regardless of which node you connect to in the console, you will see a cluster-wide view.
So with this background now you know the answer to your other two questions:
What should be the strategy for implementing high availability? / how to make RMQ2 accept messages?
From your description, you are looking for the failover that high availability is intended to provide. You need to enable this on your cluster. This is done through a policy, and there are various ways to do it, but the easiest way is in the management console on the Admin tab in the Policies section:
The previously cited doc has more detail on what it means to configure high availability in Rabbit.
What this will give you is mirroring of queues and messages across your cluster. That way, if RMQ1 fails then RMQ2 will still have your queues and messages since they are mirrored across both nodes.
An important note is that Rabbit will not automatically detect a loss of connection to RMQ1 and connect you to RMQ2. Your client needs to do this. I see you tagged your question with EasyNetQ. EasyNetQ provides this "failover connect" type of feature for you. You just need to supply both node hosts in the connection string. The EasyNetQ doc on clustering has details. Note that EasyNetQ even lets you inject a simple load balancing strategy in this case as well.
I am sending a message to rabbitMQ, I want to read this message and log it into a file.
How can I do this?
In order to trace all the messages being exchanged on the RabbitMQ server you can use the firehose tracer.
You can activate/deactivate it with the commands:
rabbitmqctl trace_on
rabbitmqctl trace_off
Once activated, all the messages will be duplicated to the exchange amq.rabbitmq.trace.
Just bind a queue to it and consume from there. You can find a working example in our RabbitMQ Cookbook.
It should also be possible to directly trace the messages to file by using the rabbitmq_tracing plugin, but I have never tried it actually.
I've got an application which has some bugs. For some reason 2 consumers are created when only one should be there - and one of them is not checked for messages anymore.
I can detect that situation by listing queues and the number of consumers on the server. Is there some way to destroy that consumer from the server side?
consumer can be kill by rabbitmqctl using close_connection input connectionpid
example
> rabbitmqctl close_connection "<rabbit#hardys-Mac-mini.1.4195.0>" "reason here"
connectionpid can get by
> rabbitmqctl list_consumers
Listing consumers ...
send_email_1 <rabbit#hardys-Mac-mini.1.4185.0> amq.ctag-oim8CCP2hsioWc-3WwS-qQ true 1 []
send_email_2 <rabbit#hardys-Mac-mini.1.4195.0> amq.ctag-WxpxDglqZQN2FNShN4g7QA true 1 []
RabbitMQ 3.5.4
You can kill connections to the RabbitMQ broker using the rabbitmqctl tool (see the man page) or by using the Web UI. You could also purge and delete the queue which belonged to the rogue consumer.
However, you can't kill the consumer process itself using those tools. You really should just focus on fixing the bugs in the application so that only the correct number of consumers get created.
You need to mark you consumer as "exclusive". Then only one consumer is registered with queue and other consumers are ignored even they tries to get data from that queue.