This link has been bookmarked by 8 people . It was first bookmarked on 10 Jan 2010, by Joel Coppin.
-
09 May 11
-
When I create an exchange does it stay created or does the exchange disappear anytime the client disconnects?
Whether they disappear in time or not depends on the options that you set when you declare an exchange. One option is durability, which means an exchange will survive a server restart. Autodelete is another option that indicates that the server should remove an exchange when all queues have stopped using it.
-
Why can durable queues only bind to durable exchanges?
This is just an artifact of the two tier model in AMQP. You either want to be 100% durable in all tiers, or you don't.
-
From the AMQP specification: "This flag tells the server how to react if a message cannot be routed to a queue". Specifically, if mandatory is set and after running the bindings the message was placed on zero queues then the message is returned to the sender (with a basic.return). If manadatory had not been set under the same circumstances the server would silently drop the message."
-
Can you explain how the immediate flag affects message routing?
From the AMQP specification: "This flag tells the server how to react if the message cannot be routed to a queue consumer immediately". The languange here is a little ambiguous but, to the best of our understanding (and this is what RabbitMQ implements), we take it to mean the following.
For a message published with immediate set, if a matching queue has ready consumers then one of them will have the message routed to it. If the lucky consumer crashes before ack'ing receipt the message will be requeued and/or delivered to other consumers on that queue (if there's no crash the messaged is ack'ed and it's all done as per normal). If, however, a matching queue has zero ready consumers the message will not be enqueued for subsequent redelivery on from that queue. Only if all of the matching queues have no ready consumers that the message is returned to the sender (via basic.return).
-
I have read that RabbitMQ preserves the order of messages in queues. Is this correct?
For the most part, yes. Say a publisher publishes messages M1, M2, M3 and M4 (in that order) on the same channel and with the same routing information. If these messages are routed to a queue then they will end up in the same order that they were published. Consuming on the queue will yield M1, M2, M3 and then M4.
However, the order is only guaranteed in the absence of requeuing. A message will be implicitly requeued if a consumer closes the channel before ack'ing a message. For example, if a consumer receives M1, fails to ack and closes the channel then the next consumer will receive messages in the order M2, M3, M4, M1. Messages can also be explicitly requeued if the consumer calls basic.recover{requeue=true}. The FAQ on at least once delivery talks about this in some more detail.
-
Is RabbitMQ transactional?
Yes. RabbitMQ implements AMQP's "TX" message class, which provides atomicity and durability properties to those clients that request them.
-
Does RabbitMQ support clustering, and high-availability through live failover?
Yes. RabbitMQ brokers can be made up of an arbitrary number of nodes, each of which is available for AMQP clients to connect to and interact with. RabbitMQ's routing tables are shared across the entire cluster, and delivery of messages published at one node to a queue residing at another node is seamless. For details see the clustering guide and the high availability guide.
-
Does RabbitMQ support store-and-forward?
Yes, RabbitMQ, and AMQP in general, supports store-and-forward-style exchanges and queues.
-
At what point is a message delivered, from the sender's perspective?
Publication is an asynchronous activity - in other words, a message is "published" as soon it has left the client's TCP stack. The client has no knowledge of to whom the message is delivered. If you want some guarantees, you can use the mandatory and immediate flags on basic.publish, and you can also use transactional mode. In transactional mode, publishes are batched on the broker, until you issue a tx.commit. When you get the tx.commit-ok message back (i.e. commit is synchronous), you know the broker really has received the messages.
-
Can you explain the cases where a message might be delivered to a consumer more than once?
If a message is delivered to a consumer, and that consumer then dies (or closes the channel which has the subscription to the queue, or closes the connection itself) without acking the message, then RabbitMQ will reinject the message into the queue. If that same consumer then reconnects and creates a new subscription to the same queue, it's possible it'll receive the same message again. This is 'at least once' delivery and is very deliberate design to ensure that messages are not lost in transit.
The consumer can also call basic.recover which tells rabbit to resend all the messages sent to the consumer for which rabbit has not received an ack for. This basically amounts to the consumer saying "I know you sent me some messages, but I've forgotten what they are. Could you resend them all again?".
-
What happens when a node runs out of message memory? Does the node fall over?
The RabbitMQ server has the ability to write messages to disk and forget them from memory should memory pressure occur. This allows RabbitMQ to store vastly more messages than can fit in RAM. Because of the fact that hard discs are slower than RAM, there are occasions where RabbitMQ will block producers when absolutely necessary to allow it to write out messages to disk in order to free up RAM.
-
What limitations are there on message size? For example, If I have a box with 8GB of RAM will it be able to hold one 8GB message?
The main limitation is installed memory on the server (or, more accurately, the amount of per-process memory available on your platform).
However, it's not as simple as available RAM = maximum message size. This would only be possible if there was zero copying of a message from when it arrives at the machine until when it leaves. Its very likely that it will be copied several times.
We would be surprised if it's possible to push messages into RabbitMQ that are greater than 1/4 of the installed RAM. RabbitMQ tries to avoid using swap wherever possible and uses a configurable parameter to set a memory threshold above which producers are throttled.
Be aware that Windows imposes some "gotcha" constraints on per-process memory that have caught some people out in the past.
-
Can you recommend the best way to work with connections and channels in my application?
In general, it is better to create a single connection and as many channels as you need (rather than many connections with a single channel each).
-
- You don't care about replicating state and can use any other queue as a 'suitable queue'. This is easy - just make sure the right consumers and routes are wired up.
- You do care about replicating state. Then you can fail over to a passive server – this is not available out of the box but you can contact us for more information. (You can also do active/active failover but it is much more fiddly).
How can I ensure that a message can always reach a suitable queue even if the RabbitMQ node which I’m sending to crashes?
At the risk of sounding pedantic, you could wait for the dead node to recover from disk. In other words, RabbitMQ provides "eventual delivery" out of the box. If you want to persist more reliably than with a single disk then use a RAID or a SAN.
The problem with using a single node is the time it takes to recover the node and the cost (if any) of the client reconnection. The time to recover is partly influenced by how much state must be recovered and partly by the size of the unavailability window that your application can tolerate.
Many applications don't like to wait more than (say) 1ms, 10ms or 50ms before they can send their message. In this case, you will typically want to send a message _before_ the crashed node has been able to recover. You can achieve this in two ways:
-
How can I retrieve the last message published to a particular topic?
A classic use-case for messaging systems is the example of subscribing to a topic of, say, 'market prices' for an asset. By that a client very often means, "send me the last published one and then subscribe me to any update". Sometimes it is not necessary if the asset is liquid (MSFT) but if it is illiquid, the client should receive the last available message, as it's possible there will be a long delay before the next update.
Does RabbitMQ support this?
This is not something AMQP provides out-of-the-box, although one can imagine a solution involving a trivial service (a simple hash table, in effect) answering requests for most-recent-price served via AMQP. The client would subscribe to the stream as usual, and in parallel ask the service for the most recent price.
Such a service could be implemented either inside the RabbitMQ broker, in Erlang, thus taking advantage of Erlang's distribution and high-availability properties, or it could be implemented outside the broker, as a regular AMQP client.
Mike Bridgen has created an experimental last value cache, implemented using RabbitMQ's plugin exchange type. It is available to download from github.
-
What provision is there for instrumentation, logging and debugging?
RabbitMQ uses AMQP internally to the broker to notify interested parties of significant events. Administration and management exchanges are provided for tools to bind to.
Various management and monitoring tools are available from RabbitMQ and the community. Information about logging output can be found in the install guide.
-
How do I use transactions to implement atomic operations in RabbitMQ?
RabbitMQ implements AMQP's TX message class to support atomic operations with clients that request them.
If you need only to acknowledge receipt of a message you should get the consumer to send a basic.ack once its done with processing. There's no need to use tx in this case.
However, if you need to both ack a message and publish some other messages as an atomic unit then you should set tx.select on the channel to start a transaction. When processing the received message, you can publish your messages and ack; only when you finally call tx.commit do the actions of the transaction take effect. In this case, if the consumer crashes, the ack and all publications get forgotten: either all of the actions happen or nothing happens.
If, at the application level, you realise that due to some external event everything needs to be cancelled then call tx.rollback on the channel.
-
How do you migrate an instance of RabbitMQ to another machine?
Rabbit uses mnesia to replicate information about a broker (excluding messages), so you may want to read the relevant sections about administration in the mnesia guide before doing anything. Don't just copy the data directory and hope that mnesia will just magically recover this, because it could well contain inode references. Also, taking Rabbit offline to do this may be a good idea.
There is also the issue of persistent messages, which are not stored in mnesia. This needs to handled separately.
And be aware that queue processes will not automatically be migrated.
And as always, if this is production data, then taking a backup is generally a prudent idea.
If you have done this already, then send a message to the list because I'd like to write more about this question, but don't have any time.
-
How can I route messages directly from one RabbitMQ instance to another. Does Rabbit MQ support broker to broker connections?
Yes it does! Many people have asked about this use case and we've devloped an implementation that we call Shovel. You can read more about Shovel on the LShift blog.
-
When running rabbitmq behind a firewall, which ports do I need to open?
5672:tcp
-
How low can latency be?
RabbitMQ operates at sub-millisecond latency in transient mode under a load of 10k messages per second. In persistent mode, it should be possible to achieve a throughput of 3-5k messages per second stored to disk depending upon the exact configuration.
Please contact us if you would like more information relevant to your setup.
-
How fast is RabbitMQ in persistent mode?
From our testing, we expect easily-achievable throughputs of 4000 persistent, non-transacted one-kilobyte messages per second (Intel Pentium D, 2.8GHz, dual core, gigabit ethernet) from a single RabbitMQ broker node writing to a single spindle.
Please let us know how RabbitMQ performs for you!
-
How do I switch off persistence/transactionality?
To disable transactionality, use an AMQP channel which is not in "TX" mode (ie. do not call tx.select). To disable message persistence, set the "delivery mode" field in the basic-class properties for the message to either absent or to one, as mode two enables persistence.
-
What do I do if a RabbitMQ instance dies?
It depends how and why it died, of course. Please differentiate between a dead machine and a partitioned network. One quick fix for a truly dead node may be to get a backup machine, reinstall the OS and Rabbit and then just restart Rabbit with the contents of the old mnesia data directory (if the disk is still ok, then you could just try slotting it in the new machine). Make sure that the backup machine has the same name as the machine that died. If this works, you are in luck. If not, i.e. mnesia does not seem to be recovering itself (it hangs will the waiting_for_tables error message), then what you can try is to nuke the mnesia directory and bring this node as part of the cluster and let it replicate itself from the other cluster members. Note that this will not restart queue processes that were running on this node before it crashed. But you can just re-declare the queues.
-
How long does it take a node take to come back up?
RabbitMQ records whether it was shutdown safely. Using the init scripts or the rabbitmq-server script to shutdown RabbitMQ counts as a safe shutdown. If RabbitMQ is started up after a safe shutdown, then it will start up very quickly indeed, almost regardless of the number of messages on disk.
If RabbitMQ is not shutdown cleanly (e.g. it's killed, or the machine crashes), or if during startup it detects tampering of its files, it has to do many further checks to reach a consistent state from the data it recovers from disk. This can take several minutes when many millions of messages are involved.
-
Can a node's state get corrupted such that it cannot come back online? Is there a recovery tool?
State is only stored on disk if it must be recoverable. For durable queues / exchanges / bindings, we use mnesia. If mnesia is unable to start and read in the tables recording this information then RabbitMQ cannot start or recover those queues / exchanges / bindings.
RabbitMQ itself manages the storage on disk of messages. The recovery routines for these are robust and do their best to recover as much as possible. If corruption occurs, RabbitMQ will recover what it can, and continue to start up normally.
-
How many virtual hosts can I run and where?
There is no hard limit to the number of virtual hosts that can be configured within a RabbitMQ cluster, save available disk and memory resources.
Virtual hosts within AMQP are decoupled from the physical network layout: one virtual host can be accessed from multiple clustered brokers, just as many virtual hosts can be accessed within a single broker. Virtual hosts act solely as a namespacing mechanism for AMQP resources.
We want to get to the point where one can dynamically add and remove nodes to/from a cluster that represents one logical AMQP broker, for both reliability and scalability (to very high numbers of nodes).
This is an important area for us, and one of the reasons we chose Erlang/OTP as the implementation platform for RabbitMQ.
-
How are the connections secured? HTTPS or something else? What about certificate management?
The standard only defines basic username/password authentication. There are plans to extend that with SASL or some such mechanism.
It should be possible to add SSL/TLS quite trivially. Certificate management would be done in a similar fashion to most other SSL/TLS-enable apps.
-
Is the wire protocol pure binary or is there some XML mixed in? Slap me and point me to the documentation if the answer is obvious.
The protocol is pure binary.
-
-
28 Feb 11
-
18 Feb 11Steinar Rune Eriksen
"the actions of the transaction take effect. In this case, if the consumer crashes, the ack and all publications get forgotten: either all of the actions happen or nothing happens.
If, at the application level, you realise that due to some external event everything needs to be cancelled then call tx.rollback on the channel.
How do I test RabbitMQ?
You can test the RabbitMQ broker by:
* connecting to our demo server using one of the RabbitMQ example programs
* connecting to our demo server using another AMQP 0-8/0-9/0-9-1 compatible client
* Downloading the broker and experimenting with it on your own machine " -
10 Jan 10
-
What is the Open Telecom Platform (OTP)?
The Open Telecom Platform (OTP) is a battle-tested library of management, monitoring, and support code for constructing extremely high-performance, reliable, scalable, available (nine nines!) distributed network applications. It is written in Erlang.
-
When I create an exchange does it stay created or does the exchange disappear anytime the client disconnects?
Whether they disappear in time or not depends on the options that you set when you declare an exchange. One option is durability, which means an exchange will survive a server restart. Autodelete is another option that indicates that the server should remove an exchange when all queues have stopped using it.
-
Is RabbitMQ reliable and highly-available?
Yes. RabbitMQ is built atop the industry-leading OTP Erlang libraries, which provides a solid foundation for building reliable software. The underlying system supporting the Rabbit codebase has been used by Ericsson to achieve nine nines (99.9999999%) of availability.
-
Does RabbitMQ support clustering, and high-availability through live failover?
Yes. RabbitMQ brokers can be made up of an arbitrary number of nodes, each of which is available for AMQP clients to connect to and interact with. RabbitMQ's routing tables are shared across the entire cluster, and delivery of messages published at one node to a queue residing at another node is seamless. For details see the clustering guide. We are currently developing further support for live failover of AMQP resources within a cluster.
-
- it scales to hundreds of thousands of parallel processes ("green threads") within a single virtual machine, bounded only by available memory;
- the failure model for local inter-process communication (IPC) is the same as that for distributed IPC, making the transition from non-distributed to distributed code very smooth;
- binary pattern-matching constructs within the language ensure straightforward and efficient translation between wire-level encodings and internal Erlang data structures;
- finally, the OTP libraries shipped with the Erlang distribution include the notion of a supervisor/worker relationship, where supervisor processes monitor and restart worker processes under their control, making management of the entire process hierarchy within a server deterministic and automatic.
How does clustering work?
RabbitMQ's current clustering mechanisms are built around Erlang's native support for reliable distributed programming. This is a deeply sophisticated framework, implemented at the language and virtual-machine level.
Some of the unique points about Erlang's networking and distribution model are:
Within an Erlang node cluster, Erlang's native high-speed messaging is used to provide an efficient way of distributing work across the cluster. Individual AMQP clients connect to machines within the cluster, and Erlang's distributed routing database routes AMQP messages to the appropriate endpoints.
-
How does failover and HA work?
Currently, AMQP durable queues and their persistent messages are recovered from disk at each server restart. Exchange failover is handled by OTP's support for clustering (see above).
-
How is RabbitMQ scaled and the load balance handled?
At the core we are relying on Erlang/OTP to distribute one logical AMQP broker across several physical nodes, with the necessary broker state being maintained in an instance of OTP's distributed database Mnesia. There are certain aspects of the AMQP spec that are currently undergoing revision that impact this area, so watch out for associated new features and documentation in future releases of RabbitMQ.
-
How low can latency be?
RabbitMQ operates at sub-millisecond latency in transient mode under a load of 10k messages per second.
-
How fast is RabbitMQ in persistent mode?
From our testing, we expect easily-achievable throughputs of 4000 persistent, non-transacted one-kilobyte messages per second (Intel Pentium D, 2.8GHz, dual core, gigabit ethernet) from a single RabbitMQ broker node writing to a single spindle.
-
How does RabbitMQ's performance scale with clustering?
Based on typical OTP application scalability, we expect close-to-linear scaling.
-
There is no hard limit to the number of virtual hosts that can be configured within a RabbitMQ cluster, save available disk and memory resources.
-
How many concurrent connections can RabbitMQ support?
You mean concurrent TCP connections? In theory as many as the operating system will give you. If there are any niggles they can be sorted out quite easily.
Also note that AMQP allows you to multiplex AMQP sessions across a single TCP connection.
-
What advantages/disadvantages are there to having redundancy at the broker, rather than node, level?
Replicated brokers allow you to do active/active HA setups. However, you have to manually ensure that the topology of the brokers is kept the same and you must manually do deduplification on the consumers. This is very much a RAID-1 style solution. Clusters, on the other hand, are closer to RAID-0 from the point of view of queues, but exchanges and bindings are replicated to every node in the cluster.
-
In your clustering guide, it says that nodes in a cluster perform some basic load balancing. Can you explain a bit more about this works?
Right. It's very basic. Nodes can respond to a client connection attempt with AMQP's connection.redirect method (unless the client supressed redirection by setting the insist flag in connection.open. Currently, we do this by looking at the load average of each node and picking the least loaded. This is not ideal and in some cases is suboptimal. For example, when the redirected client goes on to consume from a queue on a different node. We should point out that the redirect ability of AMQP disappears in 0-91 as it's really not the job of AMQP to be doing this.
-
-
28 Jun 09
-
06 Jun 09
Would you like to comment?
Join Diigo for a free account, or sign in if you are already a member.