RabbitMQ - RabbitMQ STOMP Adapter
RabbitMQ STOMP Adapter
plugin adds support for the STOMP
protocol to . The adapter supports
with some extensions and restrictions (described ).
Installing from binary
The STOMP adapter is included in the RabbitMQ distribution.
rabbitmq-plugins enable rabbitmq_stomp
Compiling and installing from source
To build the STOMP adapter from source, follow the instructions for
building the umbrella repository contained in the
You need to install the rabbitmq_stomp.ez and amqp_client.ez packages.
Configuring the adapter
When no configuration is specified the STOMP Adapter will listen on
all interfaces on port 61613 and have a default user login/passcode
of guest/guest.
To change this, edit your
to contain a tcp_listeners variable for the rabbitmq_stomp application.
For example, a complete configuration file which changes the listener
port to 12345 would look like:
{rabbitmq_stomp, [{tcp_listeners, [12345]}]}
while one which changes the listener to listen only on localhost (for
both IPv4 and IPv6) would look like:
{rabbitmq_stomp, [{tcp_listeners, [{"127.0.0.1", 61613},
61613}]}]}
TLS/SSL Support
To use SSL for STOMP connections,
in the broker. To enable
STOMP SSL connections, add a listener configuration to the
ssl_listeners variable for the rabbitmq_stomp application. For example:
{ssl_options, [{cacertfile, "/path/to/tls/ca/cacert.pem"},
{certfile,
"/path/to/tls/server/cert.pem"},
"/path/to/tls/server/key.pem"},
verify_peer},
{fail_if_no_peer_cert, true}]}
{rabbitmq_stomp, [{tcp_listeners, [61613]},
{ssl_listeners, [61614]}]}
This configuration creates a standard TCP listener on port 61613 and
an SSL listener on port 61614.
Default User
The RabbitMQ STOMP adapter allows CONNECT frames to omit the login
and passcode headers if a default is configured.
To configure a default login and passcode, add a default_user
section to the rabbitmq_stomp application configuration. For example:
{rabbitmq_stomp, [{default_user, [{login, "guest"},
{passcode, "guest"}]}]}
The configuration example above makes guest/guest the default
login/passcode pair.
Authentication with SSL client certificates
The STOMP adapter can authenticate SSL-based connections by extracting
a name from the client's SSL certificate, without using a password.
For safety the server must be configured with the SSL options
fail_if_no_peer_cert set to true and verify set to verify_peer, to
force all SSL clients to have a verifiable client certificate.
To switch this feature on, set ssl_cert_login to true for the
rabbitmq_stomp application. For example:
{rabbitmq_stomp, [{ssl_cert_login, true}]}
By default this will set the username to an RFC4514-ish string form of
the certificate's subject's Distinguished Name, similar to that
produced by OpenSSL's "-nameopt RFC2253" option.
To use the Common Name instead, add:
{rabbit, [{ssl_cert_login_from, common_name}]}
to your configuration.
Note that:
The authenticated user must exist in the configured authentication / authorisation backend(s).
Clients must not supply login and passcode headers.
Implicit Connect
If you configure a default user or use SSL client certificate
authentication, you can also choose to allow clients to omit the
CONNECT frame entirely. In this mode, if the first frame sent on a
session is not a CONNECT, the client is automatically connected as
the default user or the user supplied in the SSL certificate.
To enable implicit connect, set implicit_connect to true for the
rabbit_stomp application. For example:
{rabbitmq_stomp, [{default_user,
[{login, "guest"},
{passcode, "guest"}]},
{implicit_connect, true}]}
Implicit connect is not enabled by default.
Note: A client causing an implicit connect will not receive a
CONNECTED frame from the server.
Testing the Adapter
If the default STOMP adapter is running, you should be able to connect to port 61613
using a STOMP client of your choice. In a pinch, telnet or netcat
(nc) will do nicely. For example:
$ nc localhost 61613
: CONNECTED
: session:session-QaDdyL5lg5dUx0vSWrnVNg==
: heart-beat:0,0
: version:1.0
DISCONNECT
Here $ i responses are prefixed with :
(your session-id may vary);
and Ctrl-@ (^@) inserts a zero byte into the stream.
We connect as the default user (note the blank line
after the CONNECT line) getting a CONNECTED response indicating
that the STOMP adapter is listening and running.
The DISCONNECT frame
causes the connection to be dropped.
The script test.py runs a suite of tests and this can be run
using make test against a STOMP adapter built from source.
Destinations
The STOMP specification does not prescribe what kinds of destinations
a broker must support, instead the value of the destination header
in SEND and MESSAGE frames is broker-specific. The RabbitMQ STOMP
adapter supports a number of different destination types:
/exchange -- SEND to arbitrary routing keys and SUBSCRIBE to
/queue -- SEND and SUBSCRIBE to queues managed by the STOMP
/amq/queue -- SEND and SUBSCRIBE to queues created outside the
/topic -- SEND and SUBSCRIBE to transien
/temp-queue/ -- create temporary queues (in reply-to headers only).
AMQP 0-9-1 Semantics
The destination header on a MESSAGE frame is set as though the
message originated from a SEND frame:
messages published to the default exchange are given the destination
/queue/queuename;
messages published to amq.topic are given the destination
/topic/routing_key;
all other messages are given the destination
/exchange/exchange_name[/routing_key].
If /, % or non-ascii bytes are in the queuename, exchange_name
or routing_key, they are each replaced with the sequence %dd,
where dd is the hexadecimal code for the byte.
Because of these rules the destination on a MESSAGE frame may not
exactly match that on a SEND that published it.
Different destinations have different queue parameter defaults.
They can be controlled explicitly via headers, as explained further
in this guide.
Exchange Destinations
Any exchange/queue or exchange/routing-key combination can be accessed
using destinations prefixed with /exchange.
For SUBSCRIBE frames, a destination of the form
/exchange/&name&[/&pattern&] can be used. This destination:
creates an exclusive, auto-delete queue on &name&
if &pattern& is supplied, binds the queue to &name& exchange
using &pattern&; and
registers a subscription against the queue, for the current STOMP session.
For SEND frames, a destination of the form
/exchange/&name&[/&routing-key&] can be used. This destination:
sends to exchange &name& with the routing key &routing-key&.
Note: Exchange destinations are not suitable for
consuming messages from an existing queue. A new queue is created for
each subscriber and is bound to the specified exchange using the
supplied routing key. To work with existing queues, use
destinations.
Queue Destinations
For simple queues, destinations of the form /queue/&name& can be
Queue destinations deliver each message to at most one
subscriber. Messages sent when no subscriber exists will be queued
until a subscriber connects to the queue.
AMQP 0-9-1 Semantics
For SUBSCRIBE frames, these destinations create a shared queue &name&. A
subscription against the queue &name& is created for the current STOMP
For SEND frames, a shared queue &name& is created on the first SEND to
this destination in this session, but not subsequently. The message is sent to
the default exchange with the routing key &name&.
If no queue parameters are specified, queue will be assumed to be
durable, non-exclusive, non-autodeleted.
AMQ Queue Destinations
To address existing queues created outside the STOMP adapter,
destinations of the form /amq/queue/&name& can be used.
AMQP 0-9-1 Semantics
For both SEND and SUBSCRIBE frames no queue is created.
For SUBSCRIBE frames, it is an error if the queue does not exist.
For SEND frames, the message is sent directly to the existing queue named
&name& via the default exchange.
For SUBSCRIBE frames, a subscription against the existing queue &name& is
created for the current STOMP session.
If no queue parameters are specified, queue will be assumed to be
durable, non-exclusive, non-autodeleted.
Topic Destinations
For simple topic destinations which deliver a copy of each message to
all active subscribers, destinations of the form /topic/&name& can
be used. Topic destinations support all the routing patterns of AMQP
topic exchanges.
Messages sent to a topic destination that has no active subscribers
are simply discarded.
AMQP 0-9-1 Semantics
For SEND frames, the message is sent to the amq.topic exchange
with the routing key &name&.
For SUBSCRIBE frames, an autodeleted, non-durable queue is created and bound to the
amq.topic exchange with routing key &name&. A subscription is
created against the queue.
Durable Topic Subscriptions
The STOMP adapter supports durable topic subscriptions. Durable
subscriptions allow clients to disconnect from and reconnect to the
STOMP broker as needed, without missing messages that are sent to the
Topics are neither durable nor transient, instead subscriptions
are durable or transient. Durable and transient can be mixed against a
given topic.
Creating a Durable Subscription
To create a durable subscription, set the durable header to
true in the SUBSCRIBE frame. persistent is also supported as an alias for
durable for backwards compatibility with earlier plugin versions.
When creating a durable subscription to a topic destination,
set auto-delete to false to make sure the queue that backs your
subscription is not deleted when last subscriber disconnects.
When creating a durable subscription,
the id header must be specified. For example:
destination:/topic/my-durable
durable:true
auto-delete:false
AMQP 0-9-1 Semantics
For SEND frames, the message is sent to the amq.topic exchange
with the routing key &name&.
For SUBSCRIBE frames, a shared queue is created for each distinct
subscription ID x destination pair, and bound to the amq.topic
exchange with routing key &name&. A subscription is created against
the queue.
Deleting a Durable Subscription
To permanently delete a durable subscription, send an UNSUBSCRIBE frame for
the subscription ID with the same durable and auto-delete header values as when
subscribing.
For example:
UNSUBSCRIBE
durable:true
auto-delete:false
Temp Queue Destinations
Temp queue destinations allow you to define temporary destinations
in the reply-to header of a SEND frame.
Temp queues are managed by the broker and their identities are private to
each session -- there is no need to choose distinct names for
temporary queues in distinct sessions.
To use a temp queue, put the reply-to header on a SEND frame and
use a header value starting with /temp-queue/. For example:
destination:/queue/reply-test
reply-to:/temp-queue/foo
Hello World!
This frame creates a temporary queue (with a generated name) that is private
to the session and automatically subscribes to that queue.
A different session that uses reply-to:/temp-queue/foo will have a new,
distinct queue created.
The internal subscription id is a concatenation of the string
/temp-queue/ and the temporary queue (so /temp-queue/foo
in this example). The subscription id can be used to identify reply
messages. Reply messages cannot be identified from the destination
header, which will be different from the value in the reply-to
header. The internal subscription uses auto-ack mode and it cannot be
cancelled.
The /temp-queue/ destination is not the name of the destination
that the receiving client uses when sending the reply. Instead, the
receiving client can obtain the (real) reply destination queue name
from the reply-to header of the MESSAGE frame.
This reply
destination name can then be used as the value of the destination
header in the SEND frame sent in reply to the received
Reply destination queue names are opaque and cannot be inferred from
the /temp-queue/ name.
SEND and SUBSCRIBE frames must not contain /temp-queue
destinations in the destination header. Messages cannot be sent to
/temp-queue destinations, and subscriptions to reply queues are
created automatically.
AMQP 0-9-1 Semantics
Each /temp-queue/ corresponds to a distinct anonymous, exclusive,
auto delete queue. As such, there is no need for explicit clean up of
reply queues.
User generated queue names for Topic and Exchange destinations
When subscribing to an exchange or topic destination, RabbitMQ would generate
a queue name by default. Starting with version 3.5.7, is it possible to provide
a custom name using the x-queue-name header:
destination:/topic/alarms
x-queue-name:my-alarms-queue
Controlling RabbitMQ Queue Parameters with STOMP
As of RabbitMQ 3.6.0, it is possible to control queue parameters via STOMP
durable (aliased as persistent)
auto-delete
plus optional arguments ("x-arguments") for controlling dead lettering,
queue and message TTL, queue limits, etc:
x-dead-letter-exchange
x-dead-letter-routing-key
x-message-ttl
x-max-length
x-max-length-bytes
x-max-length-bytes
x-max-priority
The meaning of every header is the same as when a queue is declared over AMQP 0-9-1.
Please consult the rest of the documentation for details.
Using Policies with STOMP
allow for flexible,
centralised attribute configuration of queues and exchanges. Policies can
be used with queues used by the STOMP plugin.
Policies make it possible to use more RabbitMQ features with STOMP:
All server-named queues created by the STOMP plugin are prefixed with stomp-
which makes it easy to match the queues in a policy. For example, to limit
STOMP queue length to 1000 messages, create the following policy:
rabbitmqctl set_policy stomp-queues "^stomp-" '{"max-length":1000}' --apply-to queues
Note that only one policy is applied to a queue at a time, so to specify
multiple arguments (e.g. queue length limit and dead lettering) one
needs to put them into a single policy.
Protocol Extensions and Restrictions
The RabbitMQ STOMP adapter relaxes the protocol on CONNECT
and supports a number of non-standard headers on certain
frames. These extra headers provide access to features that are not
described in the STOMP specs. In addition, we prohibit some headers which
are reserved for server use. The details are given below.
Connection and Virtual Hosts
The CONNECT (or STOMP) frame in
mandatory host header (to select the virtual host to use for the
connection). The RabbitMQ adapter allows this to be optional.
When omitted, the default virtual host (/) is presumed.
To configure a different default virtual host, add a default_vhost
section to the rabbitmq_stomp application configuration, e.g.
{rabbitmq_stomp, [{default_vhost, &&"/"&&}]}
If a host header is specified it must be one of the
virtual hosts known to the RabbitMQ server, otherwise the connection is
rejected. The host header is respected even if the STOMP 1.0 version is
negotiated at the time of the connect.
Message Persistence
On the SEND frame, the STOMP adapter supports the inclusion of a persistent header.
Setting the persistent header to true has the effect of making the message persistent.
Receipts for SEND frames with persistent:true are not sent until a
confirm is received from the broker. The exact semantics for confirms
on persistent messages can be found .
MESSAGE frames for persistent messages will contain a persistent:true
RabbitMQ STOMP plugin supports auto, client, and client-individual
subscription headers that affect how ACK on NACK operations work.
The auto mode uses automatic acknowledgements. The client mode is manual
(client-driven) acknowledgements of multiple messages at once. The client-individual
is for message-by-message manual acknowledgement.
NACK frames can optionally carry the requeue header which controls whether
the message will be requeued or discarded/dead lettered. Default value is true.
The prefetch count for all subscriptions is set to unlimited by
default. This can be controlled by setting the prefetch-count header
on SUBSCRIBE frames to the desired integer count.
Header prohibited on SEND
It is not permitted to set a message-id header on a SEND frame.
The header and its value is set by the server on a MESSAGE frame sent
to a client.
Queue Properties
SEND frames also allow headers corresponding to the AMQP properties
available when publishing messages. These headers are also set on
MESSAGE frames sent to clients.
All non-deprecated AMQP 0-9-1 properties (content-type,
content-encoding, headers, delivery-mode, priority,
correlation-id, reply-to, expiration, message-id, timestamp,
type, user-id and app-id) are supported. The following special
rules apply:
amqp-message-id in STOMP is converted to message-id in AMQP, and
vice-versa.
The reply-to header causes temporary queues to be created (see
Some x-prefixed STOMP headers are translated into optional queue arguments
(see below).
Optional Queue Properties
As of RabbitMQ 3.5.5, SEND and SUBSCRIBE frames accepts a set of headers to configure the queue behaviour,
for example, use
or similar extensions.
The list of supported headers is
For example, if you want to use priority queues with STOMP, you
can SUBSCRIBE (or SEND) with the following header:
destination:/queue/my-priority-queue
x-max-priority:5
Queue Immutability
Once a queue is declared, its properties cannot be changed. Optional arguments
can be modified with . Otherwise the queue has to be deleted
and re-declared. This is true for STOMP clients as well as AMQP 0-9-1.Stay hungry, stay foolish.
2014年九月
891011121314
15161718192021
22232425262728由于种种原因，RabbitMQ到目前为止，官方还没有实现优先级队列，只实现了Consumer的优先级处理。
但是，迫于种种原因，应用层面上又需要优先级队列，因此需求来了：如何为RabbitMQ加入优先级队列特性。
查询资料后，得知RabbitMQ虽然官方没有支持此特性，但是社区已经有相关优先级队列插件了，并且这个插件被列在RabbitMQ官方网站中了。
地址如下：
不要立刻下载这个url中的那个链接，要先根据你想要更新目标的rabbitmq版本再去另外一个地方下载相应插件，如：
会列出两大版本的插件目录（选择对应目录进入下载，否则会报错...）：
插件如何安装？
进入rabbitmq安装目录，进入plugins目录，将上面这个ez文件拷贝到plugins目录中，然后运行命令来enable这个插件
centos下，默认路径在:/usr/lib/rabbitmq/lib/rabbitmq_server-3.3.4/plugins（版本号可能会变化）
windows下，默认路径在:C:\Program Files\RabbitMQ Server\rabbitmq_server-3.3.4\plugins（版本号可能会变化）
把ez文件拷贝过去，然后运行列举插件列表命令：
找到这个优先级队列插件名为：rabbitmq_priority_queue
执行：rabbitmq-plugins enable rabbitmq_priority_queue
ok，重新启动rabbitmq-server服务。
这样，server端的配置算完成了。
C#代码端需要作出的更改
下面看看客户端类库的编写：
我们先要定义优先级枚举，继承自byte，因为RabbitMQ的C#客户端优先级是用byte来传递的：
先定义3个级别的优先级：低、中、高（其实可以定义很多级别，只是为了简化，因此只定义了3个级别）
有2个地方需要改动：
申明队列时需要加入自定义的属性
发送消息到rabbitmq时，设置自定义属性
internal static IDictionary&string, object& QueueArguments
IDictionary&string, object& arguments=new Dictionary&string, object&();
arguments["x-max-priority"] = 10;//定义队列优先级为10个级别
channel.QueueDeclare("queueName", true, false, false, QueueArguments);//QueueArguments就是上面定义的这个dictionary
var headers = channel.CreateBasicProperties();
headers.Priority = (byte)msg.P//在这里把继承自byte的枚举转换成byte
channel.BasicPublish("exchange", "route", headers, SerializerUtility.Serialize2Bytes(msg));
&其他注意的地方
在装了优先级队列插件的rabbitmq-server实例中，所有的Durable队列必须用如上的方式，设置x-max-priority属性，否则rabbitmq-server服务会crash
阅读(...) 评论()当前访客身份：游客 [
研究过的内容： 1.基于P2P的流媒体2.RabbitMQ 3.分布式+数据库（起步阶段） 4.Erlang（初级开发） 5.数据库代理 6.基于HTTP实现的微博SDK
：引用来自“David_Alpha_Fox”的评论点赞谢...
：引用来自“hncscwc”的评论看来是留了个不小的坑...
：看来是留了个不小的坑啊～～ 还有，确实是需要长...
：引用来自“杨鬼”的评论问问能不能开源吧~~这么好...
：引用来自“Loveni”的评论不如打开发文档公开 还...
：问问能不能开源吧~~这么好的东西.
：不如打开发文档公开
：引用来自“红薯”的评论 都总结出来，那不如开源...
今日访问：13
昨日访问：101
本周访问：560
本月访问：560
所有访问：133336
【原创】RabbitMQ 之 TTL 详解（翻译）
发表于3年前( 10:24)&&
阅读（1929）&|&评论（）
0人收藏此文章,
RabbitMQ官方文档中关于TTL的内容
Time-To-Live Extensions
RabbitMQ allows you to set Time To Live for both messages and queues. RabbitMQ 允许你针对 message 和 queue 设置 TTL 值。
Per-Queue Message TTL
The x-message-ttl argument to queue.declare controls for how long a message published to a queue can live before it is discarded. TTL can be set for a given queue by setting the x-message-ttl argument to queue.declare, or by setting the message-ttl policy.A message that has been in the queue for longer than the configured TTL is said to be dead. Note that a message routed to multiple queues can die at different times, or not at all, in each queue in which it resides. The death of a message in one queue has no impact on the life of the same message in other queues. 通过在 queue.declare 中设置 x-message-ttl 参数，可以控制被 publish 到 queue 中的 message 被丢弃前能够存活的时间。可以通过设置名为 x-message-ttl 的 arugment 到 queue.declare ，或者通过设置名为 message-ttl 的 ，来控制 queue 中 message 的存活时间。当某个 message 在 queue 留存的时间超过了配置的 TTL 值时，我们说该 message “已死”。值得注意的是，当一个 message 被路由到多个 queue 中时，其可以在不同的时间“死掉”，或者可能有的不会出现“死掉”情况。在某个 queue 中的某个 message 的“死亡”不会对相同 message 在其他 queue 中的生存状况产生影响。
The server guarantees that dead messages will not be included in any basic.get-ok or basic.deliver methods. Further, the server will try to reap messages at or shortly after their TTL-based expiry. 服务器会保证“死掉”的 message 将不会在任何 basic.get-ok 或 basic.deliver 方法中被包含。更进一步，服务器将努力在 TTL 到期或到期后的短时间内处理掉该 message 。&
The value of the x-message-ttl argument must be a non-negative 32 bit integer (0 &= n &= 2^32-1) The value of the TTL argument or policy must be a non-negative integer (0 &= n), describing the TTL period in milliseconds. Thus a value of 1000 means that a message added to the queue will live in the queue for 1 second or until it is delivered to a consumer. The argument can be of AMQP type short-short-int, short-int, long-int, or long-long-int. 参数 x-message-ttl 的值必须是非负的 32 位整数 (0 &= n &= 2^32-1) 作为 argument 或 policy 的 TTL 的值必须为非负整数(0&=n)，以毫秒为单位表示 TTL 的值。这样，值 1000 表示存在于 queue 中的当前 message 将最多只存活 1 秒钟，除非其被投递到 consumer 上。实参可以是以下 AMQP 类型：short-short-int 、short-int 、long-int 或者 long-long-int 。&
This example in Java creates a queue in which messages may reside for at most 60 seconds: 下面的 Java 实例代码创建了一个 queue ，且 message 在该 queue 的存活时间最大为 60 秒：&
Map&String, Object& args = new HashMap&String, Object&();
args.put("x-message-ttl", 60000);
channel.queueDeclare("myqueue", false, false, false, args);
To specify a TTL using policy, add the key "message-ttl" to a policy definition. For example: 若想要通过 policy 设置 TTL ，则需要将 key 值 message-ttl 添加到 policy 定义中，例如：
rabbitmqctl
rabbitmqctl set_policy TTL ".*" '{"message-ttl":60000}' --apply-to queues
rabbitmqctl (Windows)
rabbitmqctl set_policy TTL ".*" "{""message-ttl"":60000}" --apply-to queues
This applies a TTL of 60 seconds to all queues.
上述命令设置所有 queue 的 TTL 均为 60 秒。
The original expiry time of a message is preserved if it is requeued (for example due to the use of an AMQP method that features a requeue parameter, or due to a channel closure).
当 message 被 requeue 的时候，其原始过期时间将被保留（例如由于设置了 requeue 参数的 AMQP 方法的使用，或者由于 channel 的关闭）。
Setting x-message-ttl The TTL to 0 causes messages to be expired upon reaching a queue unless they can be delivered to a consumer immediately. Thus this provides an alternative to basic.publish's immediate flag, which the RabbitMQ server does not support. Unlike that flag, no basic.returns are issued, and if a dead letter exchange is set then messages will be dead-lettered.& 设置 x-message-ttl TTL 为 0 则表示，在 message 到达 queue 之后，若未被立即投递到 consumer ，则立即将其判定为过期。这种方式相当于 RabbitMQ server 不支持 basic.publish 中 immediate 标识情况下的等价实现。与采用 immediate 属性的方式不同的是，将不会有 basic.returns 命令的调用，并且在设置了 dead letter exchange 的情况下，这些 message 将被处理为 dead-lettered 。
Per-Message TTL
A TTL can be specified on a per-message basis, by setting the expiration field in the basic AMQP class when sending a basic.publish. TTL 设置可以具体到每一条 message 本身，只要在通过 basic.publish 命令发送 message 时设置 expiration 字段。&
The value of the expiration field describes the TTL period in milliseconds. The same constraints as for x-message-ttl apply. Since the expiration field must be a string, the broker will (only) accept the string representation of the number. expiration 字段以毫秒为单位表示 TTL 值。且与 x-message-ttl 具有相同的约束条件。因为 expiration 字段必须为字符串类型，broker 将只会接受以字符串形式表达的数字。&
When both a per-queue and a per-message TTL are specified, the lower value between the two will be chosen. 当同时指定了 queue 和 message 的 TTL 值，则两者中较小的那个才会起作用。&
This example in Java publishes a message which can reside in the queue for at most 60 seconds: 下面的 Java 示例 publish 了最多能在 queue 中存活 60 秒的 message ：&
byte[] messageBodyBytes = "Hello, world!".getBytes();
AMQP.BasicProperties properties = new AMQP.BasicProperties();
properties.setExpiration("60000");
channel.basicPublish("my-exchange", "routing-key", properties, messageBodyBytes);
While consumers never see expired messages, only when expired messages reach the head of a queue will they actually be discarded (or dead-lettered). When setting a per-queue TTL this is not a problem, since expired messages are always at the head of the queue. When setting per-message TTL however, expired messages can queue up behind non-expired ones until the latter are consumed or expired. Hence resources used by such expired messages will not be freed, and they will be counted in queue statistics (e.g. the number of messages in the queue). 虽然 consumer 从来看不到过期的 message ，但过期 message 只会在到达 queue 的头部时才会被真正的丢弃（或者 dead-lettered ）。当采用针对 queue 设置 TTL 的方式时，不会产生任何问题，因为过期的 message 总是会出现在 queue 的头部。但是当针对每条 message 设置了 TTL 时，已过期 message 可能会排在未过期 message 的后面，直到后者被 consume 掉或者过期。在这种情况下，这些过期的 message 使用的资源将不会被释放，且会在 queue 统计信息中被计算进去（例如，queue 中存在的 message 的数量）。
The x-expires argument to queue.declare Expiry time can be set for a given queue by setting the x-expires argument to queue.declare, or by setting the expires policy. This&controls&for how long a queue can be unused before it is automatically deleted. Unused means the queue has no consumers, the queue has not been redeclared, and basic.get has not been invoked for a duration of at least the expiration period. This can be used, for example, for RPC-style reply queues, where many queues can be created which may never be drained. queue.declare 命令中的 x-expires 参数 可以通过设置 x-expires 参数给 queue.declare 方法，或者设置名为 expires 的 policy 来设置过期时间，从而控制 queue 被自动删除前可以处于“未使用”状态的时间。“未使用”的意思是指 queue 上没有任何 consumer ，且在过期时间段内 queue 没有被重新声明，也未通过 basic.get 命令被访问过。该方式可用于，例如，RPC-style 的回复 queue ，其中许多 queue 会被创建出来，但是却从未被使用。&
The server guarantees that the queue will be deleted, if unused for at least the expiration period. No guarantee is given as to how promptly the queue will be removed after the expiration period has elapsed. Leases of durable queues restart when the server restarts.
服务器会确保在过期时间到达后 queue 被删除，但是不保证删除的动作有多么的及时。在服务器重启后，持久化的 queue 的超时时间将重新计算。&
The value of the x-expires argument or expires policy&describes the expiration period in milliseconds and is subject to the same constraints as x-message-ttl and cannot be zero . It must be a positive integer (unlike message TTL it cannot be 0). Thus a value of 1000 means a queue which is unused for 1 second will be deleted. x-expires 参数的值或者 policy 中的 expires 的值用于表示超期时间，以毫秒为单位。并且服从和 x-message-ttl 一样的约束条件，且不能设置为 0 。该值必须为正数（与消息 TTL 不同，该值不可以为 0），所以如果该参数设置为 1000 ，则表示该 queue 如果在 1 秒钟之内未被使用则会被删除。&
This example in Java creates a queue which expires after it has been unused for 30 minutes. 下面的 Java 示例创建了一个 queue ，其会在 30 分钟不使用的情况下判定为超时。&
Map&String, Object& args = new HashMap&String, Object&();
args.put("x-expires", 1800000);
channel.queueDeclare("myqueue", false, false, false, args);
The following policy does the same thing for all queues:
下面的 policy 设置可以实现和上面相同的功能：
rabbitmqctl
rabbitmqctl set_policy expiry ".*" '{"expires":1800000}' --apply-to queues
rabbitmqctl (Windows)
rabbitmqctl set_policy expiry ".*" "{""expires"":1800000}" --apply-to queues
更多开发者职位上
1)">1)">1" ng-class="{current:{{currentPage==page}}}" ng-repeat="page in pages"><li class='page' ng-if="(endIndex<li class='page next' ng-if="(currentPage
相关文章阅读