RabbitMQ: persistent message with Topic echange?

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.

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 will still be there if you restart your broker, but it does not mean that any messages sent to that exchange are automatically persisted.

Given that, here are two options: Perform an administrative step before you start your publishers to create the queue(s) yourself. You could use the web UI or the command line tools to do this. Make sure you create it as a durable queue so that it will store any messages that are routed to it even if there are no active consumers.

Assuming your consumers are coded to always declare (and therefore auto-create) their exchanges and queues on startup (and that they declare them as durable), just run all your consumers at least once before starting any publishers. That will ensure that all your queues get created correctly. You can then shut down the consumers until they're really needed because the queues will persistently store any future messages routed to them.

I would go for #1. There may not be many steps to perform and you could always script the steps required so that they could be repeated. Plus if all your consumers are going to pull from the same single queue (rather than have a dedicated queue each) it's really a minimal piece of administrative overhead.

Queues are something to be managed and controlled properly. Otherwise you could end up with rogue consumers declaring durable queues, using them for a few minutes but never again. Soon after you'll have a permanently-growing queue with nothing reducing its size, and an impending broker apocalypse.

OK, so the solution is to declare fixed client queues in the publisher script. Of course this requires me to know in advances how many consumers there will be. – Julien May 28 at 1:14 1 That's true, assuming that each consumer will need its own queue.

But the main question you need to answer is, "Will those consumers need all your historical messages which were sent before they ever came into being? ". If they won't care about old messages, they can just declare their own queue on startup and receive all messages from that point on, but nothing older.

– Brian Kelly May 28 at 18:34 1 Applications "declare" queues and then the MQ broker creates them if they do not yet exist. Although it makes sense for listener applications to declare queues, and not sender applications, you run into the problem that you have seen. It is probably the best solution to declare queues, declare exchanges, create vhost, etc.Before running an app.

– Michael Dillon May 31 at 4:42.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.