AMQP Messages

In LavinMQ, a message is information that is sent from the producer to a consumer through the LavinMQ message broker.

What is a message?

A message is the data transported between the sending and the receiving applications and is essentially a byte array led by some headers. An example of a message includes something that tells one system to start processing a task; it can contain information about a finished task or just a plain message.

Message flow LavinMQ

The producer publishes a message to an exchange. The exchange receives the message and is now responsible for routing it. The exchange routes the message into the queues depending on message attributes via bindings created between the exchange and the queue.

The messages stay in the queue until they are handled by a consumer, which ultimately handles the message.

Messages in LavinMQ

What’s included in a message depends on what kind of information the producer wishes the consumer to receive. Suppose the producer is someone requesting an image scaling application. In that case, the message will likely contain information about message settings that the receiving producer needs to be able to handle the image and so on. The information carried by a message is referred to as the payload and is not inspected or changed by the broker. Apart from the message itself, messages are also sent with certain attributes that are important for defining how and where the message should be sent within the system.

This documentation describes how the message itself is and can be configured for achieving desirable results in LavinMQ.

Message Properties and Payload

Message information can theoretically be split into bigger topics. The actual message information (payload) can be whatever the producer wishes the consumer to receive. The broker does not care about the information within the payload and it is not depending on that information to be able to route the messages correctly. The payload strictly contains application data. For broker handling, messages also come with properties, that define the message. It can be a timestamp, a user id, and so on. However, most attributes are optional, and the most common ones are implemented in the AMQP protocol and are called attributes. If the message should be routed based on other permissions than the implemented attributes, this information is included in the headers. The common name for data that is associated with a message (attributes and headers) is called message properties.

It is possible to send messages without payload and only with attributes, usually by using the attributes for defining message content such as content_type and content_encoding.

Here follows a description of the most common message attributes:

Content type & Content encoding

Includes information used by connected applications and not by LavinMQ e.g. application/JSON (content type) and e.g. gzip (content encoding). These can be used to define structured data in order to publish it as the message payload.

Routing key

The routing key is a message attribute the exchange looks at when deciding how to route the message to queues (depending on exchange type).

Delivery mode

By defining delivery mode, you are defining whether the message should be persistent or not. A persistent message is not lost in case of server failure. Setting message attribute to persistent ensures that the broker writes it to disk, meaning that it will survive a broker restart. Unfortunately, publishing persistent messages does affect performance since it requires more resources.

Message priority

Certain messages that publishers send have a higher priority than others, such as an urgent alarm or a task that needs to be handled right away. LavinMQ allows for message priority, meaning that designated messages are placed at the head of the queue and get handled immediately.

Read more about message priority.

Message publishing timestamp

As it enters LavinMQ, the message timestamp fills in this property with the server’s current value.

Expiration period

By declaring a queue with the x-message-ttl property, messages will be discarded from the queue if they haven’t been consumed within the time specified.

Publisher application id

It is sometimes valuable for consumers to know the sending producer’s identity. This is a value that can be added in the message for the consumer to be able to see from what producer the message is sent.

X-message-TTL

Time To Live (message-TTL) defines for how long a message exists before it’s considered dead. TTL can be specified for messages using ((arguments)[/documentation/arguments-and-properties] or (policies)[/documentation/policies], which is recommended. For example: If a message TTL policy of 28 days is defined, messages that have not been consumed for 28 days will be deleted. By defining a message TTL, a message that is considered dead (passed the time of delivery) will not be included in message consuming and the broker strives to remove dead messages shortly after the expired TTL limit.

LavinMQ sorts messages on TTL, which may change the head of the queue, meaning that a high TTL message won’t block a low TTL message.

TTL is defined by milliseconds with a nonnegative integer (3000 = 3 seconds) and can also be configured for queues, groups of queues, or messages.

Message Acknowledgements

Messages in transit between LavinMQ and the consumer might get lost and have to be re-sent. This can occur when a connection fails or during other events that disconnect the receiving service (consumer) from LavinMQ. The use of consumer acknowledgments assures that messages have been delivered. When it comes to message publishing, a publish confirm is the same concept.

Read more about consumer acknowledgments.

Message Ordering in LavinMQ

Messages in LavinMQ are placed onto the queue in the sequential order in which they are received. The first message is placed in position 1, the second message in position 2, and so on. Messages are then consumed from the head of the queue, meaning that message 1 gets consumed first. This is called the FIFO method (first in first out). A message received by the broker is enqueued (added to the queue). If a consumer subscribed to the queue, a message is dequeued (removed from the queue) when sent to the consumer.

Read more about message ordering in LavinMQ.

Details on the Message Store in LavinMQ

All routed messages in LavinMQ are written directly to the disk into something called a Message Store. The Message Store is a series of files (segments). A routed message is located in the Message Store, with a reference from the queue’s index to the message store.

Message Size

While the theoretical message size limit in LavinMQ is 2GB and up, we don’t recommend sending messages larger than 256MB.

Ready to take the next steps? Here are some things you should keep in mind:

Managed LavinMQ instance on CloudAMQP

LavinMQ has been built with performance and ease of use in mind - we've benchmarked a throughput of about 1,000,000 messages/sec. You can try LavinMQ without any installation hassle by creating a free instance on CloudAMQP. Signing up is a breeze.

Help and feedback

We welcome your feedback and are eager to address any questions you may have about this piece or using LavinMQ. Join our Slack channel to connect with us directly. You can also find LavinMQ on GitHub.