跳到主要内容
本页尚未翻译

下面显示的是英文原文。

Arguments

argument and arguments pass any x- declaration argument the descriptor does not model, such as a TTL or a length limit, verbatim.

A queue declaration carries a table of arguments, and RabbitMQ reads queue features from it: x-message-ttl, x-max-length, x-overflow, x-single-active-consumer and more. argument(name, value) adds one entry, and arguments(table) replaces the whole table. The value is an AMQPValue and the table a FieldTable, both re-exported from lapin. A name is at most 255 bytes, the protocol's limit for a field name. The settings the descriptor models, such as the dead-letter exchange and the queue type, travel in the same table, so they are written with their own steps.

The arguments reach the server in the queue's declaration, so they take effect where the broker declares the topology. A queue keeps the arguments it was first declared with. A declaration with other arguments is refused with PRECONDITION_FAILED, and startup fails with AmqpError::Declare; the in-process transport refuses it the same way. What an argument does to the messages, such as a TTL that expires them, is the server's work and shows only against a server.

Example​

Notifications expire after a minute, and the queue holds at most ten thousand of them. The macro form adds the arguments one by one; the manual form builds the table.

/// A notification older than a minute is no longer worth sending, and the queue keeps at most
/// ten thousand of them.
#[subscriber(RabbitQueue::new("notifications")
.argument("x-message-ttl", AMQPValue::LongLongInt(60_000))
.argument("x-max-length", AMQPValue::LongLongInt(10_000)))]
async fn notify(notification: &Notification) -> HandlerOutcome {
tracing::info!(notification.user, "notification sent");
HandlerOutcome::ack()
}