In RabbitMQ we can use temporary messages and queues. We can create a queue which is automatically deleted within some time of inactivity.
Sometimes messages are not equal between them. Some are more prioritized than the others and they should be handled first. RabbitMQ implements also a feature to deal with the problems of priorities.
RabbitMQ is not only one-direction system. Queues can communicate between them, just as two people talk together.
Sometimes consumers can be overloaded by the number of messages to handle. RabbitMQ helps to control this number with the parameter called prefetch.
RabbitMQ Java API brings a lot of methods called the same but accepting different parameters. Very often, these parameters are flags which can apply as well on messages, as on exchanges level.
It's not a surprise, transactions slow down RabbitMQ performances. It's the reason why a suggested way to manage guaranteed delivery is publisher confirms concept.
At the first look, transactions appears as an element strictly related to databases. However, we retrieve them also in messaging.
Messaging reserves surprises, especially when things go bad. It can occur when, for example, message time to live is exceeded or when there are no more space in the queue to handle new messages. To avoid messages loosing, a special kind of exchange, dead-letter exchange, exists in RabbitMQ.
Persistence is an important part of RabbitMQ configuration. Nobody would like to lose key business messages because of temporary power loss or human manipulation error.
Exchanges are key element in RabbitMQ messages transmission. Every message is firstly routed to these exchanges and only after it's dispatched to appropriate queues. A queue can't be declared without associated exchange.
RabbitMQ doesn't introduce very much new concepts to Entreprise Integration Patterns. However, it's good to know how it defines them before starting to write code.
