RabbitMQ real world scenario

What I require from usage of RabbitMQ is: The producer produces messages and receiver receives all the messages, which are published after the time it has first connected to the queue.

Since a consumer wants to consume all the messages published. Since, if more than one consumer is connected to same queue, then consumers will not receive all the messages.(Also, see here). Hence, the consumer must create an 'exclusive' queue and get connected to the desired exchange. Also, it wants to receive all the messages which were published even when it is down ( in the future). Hence the queue is 'durable'. Now, the scenario looks like :

A consumer C1 creates a queue Q1 which is exclusive and durable. Now it is down for some time and in the meantime another user C2 tries to connect to queue Q1. C2 will be successfull since, Q1 has now no subscriber connected to it. So开发者_运维问答, C2 gets connected to the exclusive and durable queue. Now, if C1 tries to connect to queue Q1 it cannot do so, since already a consumer C2 is subscribed to the queue Q1.

How one can prevent such scenario ?

I hope, I am clear this time.

---

Ahhh!! Simple answer... I wasnot Knowing this thing about consumer. Make the consumer exclusive. Now only this consumer can connect to the queue. But if the channel creating that consumer is closed, the purpose will fail. Hence, channel must never be closed, if using exclusive queues or consumers. You can find more about this here.

---

Maybe it is possible for the Consumer C2 to create its own queue with the same routing key and then receive the new messages published since then.

If the C1 comes back it can use it's previous connection. And the the both consumers receive the messages.

---

I answered this already in the similarly-named question you posted yesterday, and I'm not sure where that's gone. Did you delete it?

Anyway, the answer (again) is to use a unique naming scheme. Just make sure that your consumers employ some form of predictable but unique-per-consumer key which is used as the queue name which they declare.

It is the responsibility of your application to prevent consumer C2 from connecting to the queue intended for consumer C1. RabbitMQ is not going to magically prevent that happening.