Publishers
A publisher refers to a client application or system that creates and sends messages to LavinMQ, generating information or events to be distributed to other systems. When applications send messages, they publish or produce them.
Publishing messages
To publish messages, clients establish a connection with LavinMQ. This connection serves as a pathway for communication between the client and the message broker. Within this connection, clients create a channel, which is a virtual communication pathway that allows them to interact with the message broker. For more information, refer to the documentation on connections and channels.
Publishing to a non-existing exchange
If a message is published to a non-existing exchange, the message broker typically discards the message. This happens because the exchange is responsible for routing messages, so if it doesn’t exist, there is no way for the message to reach its intended destination. However, an Alternate Exchange can be configured to handle undelivered messages.
The publisher lifecycle
Publishers can be short-lived or long-lived. In a short-lived scenario, a publisher connects, publishes messages, and disconnects. In most cases, publishers are long-lived, maintaining a persistent connection, reusing the same channel, and publishing throughout the application’s lifetime.
Publisher confirms
Publisher confirms provide a mechanism for the publisher to know that the server has received and handled a message.
Enabling Confirms
Send confirm.select on a channel to enable publisher confirm mode. The server responds with confirm.select-ok.
Once enabled, confirms cannot be disabled on that channel.
How It Works
After confirm.select, every message published on the channel is assigned a monotonically increasing sequence number (starting from 1). After the server processes the message, it sends basic.ack or basic.nack back to the publisher with the corresponding delivery tag.
basic.ackwithmultiple=false— confirms a single messagebasic.ackwithmultiple=true— confirms all messages up to and including the delivery tagbasic.nack— the server failed to process the message (e.g., internal error). The publisher should handle this and potentially retry.
Mutual Exclusivity with Transactions
Publisher confirms and transactions (tx.select) are mutually exclusive on a channel. Enabling one after the other results in a channel error.
basic.return
When a message is published with mandatory: true and cannot be routed to any queue, the server sends basic.return before the basic.ack:
| Reply Code | Meaning |
|---|---|
| 312 | NO_ROUTE — no matching queue found |
The publisher receives basic.return first, then basic.ack. The ack confirms the server processed the message, even though it was returned.
If the mandatory flag is not set, unroutable messages are silently dropped (or sent to the alternate exchange if configured).
Ready to take the next steps?
Managed LavinMQ instance via 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.
Get started with CloudAMQP ->
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.