Unacknowledged messages are those which have been delivered across the network to a consumer but have not yet been ack’ed or rejected — but that consumer hasn’t yet closed the channel or connection over which it originally received them. Therefore the broker can’t figure out if the consumer is just taking a long time to … Read more
This is a great question. The main uses of messaging are: scaling, offloading work, integration, monitoring, event handling, routing, networking, push, mobility, buffering, queueing, task sharing, alerts, management, logging, batch, data delivery, pubsub, multicast, audit, scheduling, … and more. Basically: anything where you need data but don’t want to make a database request. (Caching is … Read more
You can actually retrieve this via the client. When you perform a queue_declare operation, RabbitMQ returns a tuple with three values: (<queue name>, <message count>, <consumer count>). The passive argument to queue_declare allows you to check whether a queue exists without modifying the server state, so you can use queue_declare with the passive option to … Read more
The immediate and mandatory fields are part of the AMQP specification, and are also covered in the RabbitMQ FAQ to clarify how its implementers interpreted their meaning: Mandatory 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 … Read more
It turns out that it is related to permissions. Somehow my rabbitmq server was started with user ‘rabbitmq’ (which is strange), so that I had to do sudo -u rabbitmq rabbitmqctl stop
At first, REST, RPC – architecture patterns, AMQP – wire-level and HTTP – application protocol which run on top of TCP/IP AMQP is a specific protocol when HTTP – general-purpose protocol, thus, HTTP has damn high overhead comparing to AMQP AMQP nature is asynchronous where HTTP nature is synchronous both REST and RPC use data … Read more
There are not any hard-coded limits inside RabbitMQ broker. The broker will utilize all available resources (unless you set limits on some of them, they are called watermarks in RabbitMQ terminology). There are some limitations put by Erlang itself, like maximum number of concurrent processes, but if you theoretically can reach them on single node … Read more
You need a durable queue to store messages if there are no connected consumers available to process the messages at the time they are published. An exchange doesn’t store messages, but a queue can. The confusing part is that exchanges can be marked as “durable” but all that really means is that the exchange itself … Read more
what makes them better than writing your own library? When rolling out the first version of your app, probably nothing: your needs are well defined and you will develop a messaging system that will fit your needs: small feature list, small source code etc. Those tools are very useful after the first release, when you … Read more
Messages marked as ‘persistent’ that are delivered to ‘durable’ queues will be logged to disk. Durable queues are recovered in the event of a crash, along with any persistent messages they stored prior to the crash.