Once we have our exchange created, we have to create a queue that can be bound to it. Queues have names so that they can be easily referenced. We can choose to provide our own queue names (which we will) or pass an empty string and have the name be generated automatically for us.

Queues have properties that we can pass to them, or use the defaults for. The properties are as follows:

• Queue name
• A durable queue will survive a service restart
• Exclusive will be used by only one connection and the queue will be deleted when that connection closes
• Auto-delete any queue that has had at least one consumer when the last consumer unsubscribes
• Arguments are optional and are server-specific name value pairs

You can think of queues as ordered collections of messages, which are consumed in First In First Out (FIFO) order. There is an exception for priority and sharded queues, but that is beyond the scope of this book.

What happens if we declare a queue as durable? Well, durable queues are persisted to disk and therefore survive microservice restarts. Non-durable queues are also called transient. It is your choice as to what you prefer to use; I prefer to keep the queues durable myself and that is the convention we will stick to in this book.

Let me point out though that just because a queue is durable does not mean that the messages going to that queue are also durable. If the service is restarted, the durable queue will be recreated during startup, but only messages marked as 'persistent' will also be recovered.

Another note about queues that we should mention is that a queue keeps messages in RAM and/or on disk, depending if they are declared persistent. Publishing a transient message will result in that message remaining in RAM when possible. It should be noted that if a queue comes under memory pressure, it will page these messages out to disk.

Since we mentioned it, let's talk a little bit about memory pressure so you can better understand how RabbitMQ handles this. The RabbitMQ server detects the total amount of RAM installed on the computer it is running on. By default (which we will not change), once the server uses above 40% of this memory (sometimes referred to as the 'memory high watermark'), it will raise a memory alarm and clock all connections that are publishing messages. Normal service resumes once the memory condition is cleared.

Keep in mind that 32 bit architectures have a memory limit of 2 GB. Most 64 bit architectures under Windows have an 8 TB limit (although AMD and Intel EM64T raise this to 256 TB). Also note that even under a 64 bit operating system, a 23 bit process only has a maximum address space of 2 GB.

With all that out of the way, let's take a look at our Subscribe method and see how we create our queue and Bind it to exchange:

public static void Subscribe()
{
Bus = RabbitHutch.CreateBus("host=localhost",
x => x.Register<IConventions, AttributeBasedConventions>());
IExchange exchange = Bus.Advanced.ExchangeDeclare("EvolvedAI", ExchangeType.Topic);
IQueue queue = Bus.Advanced.QueueDeclare("Memory");
Bus.Advanced.Bind(exchange, queue, "");
}

When the exchange is created and the queue is bound, the RabbitMQ Control Panel will show the following information. As you can see, the Memory queue is bound to this exchange (EvolvedAI); the exchange is a fanout exchange, and is durable, meaning it will survive restarts: