AnyEvent-RabbitMQ
view release on metacpan or search on metacpan
share/fixed_amqp0-8.xml view on Meta::CPAN
</field>
<field name="write" type="bit">
request write access
<doc>
Request write access to the specified access realm. Write access
lets a client publish messages to all exchanges in the realm.
</doc>
</field>
<field name="read" type="bit">
request read access
<doc>
Request read access to the specified access realm. Read access
lets a client consume messages from queues in the realm.
</doc>
</field>
</method>
<method name="request-ok" synchronous="1" index="11">
grant access to server resources
<doc>
This method provides the client with an access ticket. The access
ticket is valid within the current channel and for the lifespan of
the channel.
</doc>
<rule implement="MUST">
The client MUST NOT use access tickets except within the same
channel as originally granted.
</rule>
<rule implement="MUST">
The server MUST isolate access tickets per channel and treat an
attempt by a client to mix these as a connection exception.
</rule>
<chassis name="client" implement="MUST"/>
<field name="ticket" domain="access ticket"/>
</method>
</class>
<class name="exchange" handler="channel" index="40">
<!--
======================================================
== EXCHANGES (or "routers", if you prefer)
== (Or matchers, plugins, extensions, agents,... Routing is just one of
== the many fun things an exchange can do.)
======================================================
-->
work with exchanges
<doc>
Exchanges match and distribute messages across queues. Exchanges can be
configured in the server or created at runtime.
</doc>
<doc name="grammar">
exchange = C:DECLARE S:DECLARE-OK
/ C:DELETE S:DELETE-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="MUST"/>
<rule implement="MUST">
<test>amq_exchange_19</test>
The server MUST implement the direct and fanout exchange types, and
predeclare the corresponding exchanges named amq.direct and amq.fanout
in each virtual host. The server MUST also predeclare a direct
exchange to act as the default exchange for content Publish methods
and for default queue bindings.
</rule>
<rule implement="SHOULD">
<test>amq_exchange_20</test>
The server SHOULD implement the topic exchange type, and predeclare
the corresponding exchange named amq.topic in each virtual host.
</rule>
<rule implement="MAY">
<test>amq_exchange_21</test>
The server MAY implement the system exchange type, and predeclare the
corresponding exchanges named amq.system in each virtual host. If the
client attempts to bind a queue to the system exchange, the server
MUST raise a connection exception with reply code 507 (not allowed).
</rule>
<rule implement="MUST">
<test>amq_exchange_22</test>
The default exchange MUST be defined as internal, and be inaccessible
to the client except by specifying an empty exchange name in a content
Publish method. That is, the server MUST NOT let clients make explicit
bindings to this exchange.
</rule>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="declare" synchronous="1" index="10">
declare exchange, create if needed
<doc>
This method creates an exchange if it does not already exist, and if the
exchange exists, verifies that it is of the correct and expected class.
</doc>
<rule implement="SHOULD">
<test>amq_exchange_23</test>
The server SHOULD support a minimum of 16 exchanges per virtual host
and ideally, impose no limit except as defined by available resources.
</rule>
<chassis name="server" implement="MUST"/>
<response name="declare-ok"/>
<field name="ticket" domain="access ticket">
<doc>
When a client defines a new exchange, this belongs to the access realm
of the ticket used. All further work done with that exchange must be
done with an access ticket for the same realm.
</doc>
<rule implement="MUST">
The client MUST provide a valid access ticket giving "active" access
to the realm in which the exchange exists or will be created, or
"passive" access if the if-exists flag is set.
</rule>
</field>
<field name="exchange" domain="exchange name">
<rule implement="MUST">
<test>amq_exchange_15</test>
Exchange names starting with "amq." are reserved for predeclared
and standardised exchanges. If the client attempts to create an
exchange starting with "amq.", the server MUST raise a channel
exception with reply code 403 (access refused).
</rule>
<assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/>
</field>
<field name="type" type="shortstr">
exchange type
<doc>
Each exchange belongs to one of a set of exchange types implemented
by the server. The exchange types define the functionality of the
exchange - i.e. how messages are routed through it. It is not valid
or meaningful to attempt to change the type of an existing exchange.
</doc>
<rule implement="MUST">
<test>amq_exchange_16</test>
If the exchange already exists with a different type, the server
MUST raise a connection exception with a reply code 507 (not allowed).
</rule>
<rule implement="MUST">
<test>amq_exchange_18</test>
If the server does not support the requested exchange type it MUST
raise a connection exception with a reply code 503 (command invalid).
</rule>
<assert check="regexp" value="^[a-zA-Z0-9-_.:]+$"/>
</field>
<field name="passive" type="bit">
do not create exchange
<doc>
If set, the server will not create the exchange. The client can use
this to check whether an exchange exists without modifying the server
state.
</doc>
<rule implement="MUST">
<test>amq_exchange_05</test>
If set, and the exchange does not already exist, the server MUST
raise a channel exception with reply code 404 (not found).
</rule>
</field>
<field name="durable" type="bit">
request a durable exchange
<doc>
If set when creating a new exchange, the exchange will be marked as
durable. Durable exchanges remain active when a server restarts.
Non-durable exchanges (transient exchanges) are purged if/when a
server restarts.
</doc>
<rule implement="MUST">
<test>amq_exchange_24</test>
The server MUST support both durable and transient exchanges.
</rule>
<rule implement="MUST">
The server MUST ignore the durable field if the exchange already
exists.
</rule>
</field>
<field name="auto delete" type="bit">
auto-delete when unused
<doc>
If set, the exchange is deleted when all queues have finished
using it.
</doc>
<rule implement="SHOULD">
<test>amq_exchange_02</test>
The server SHOULD allow for a reasonable delay between the point
when it determines that an exchange is not being used (or no longer
used), and the point when it deletes the exchange. At the least it
must allow a client to create an exchange and then bind a queue to
it, with a small but non-zero delay between these two actions.
</rule>
<rule implement="MUST">
<test>amq_exchange_25</test>
The server MUST ignore the auto-delete field if the exchange already
exists.
</rule>
</field>
<field name="internal" type="bit">
create internal exchange
<doc>
If set, the exchange may not be used directly by publishers, but
only when bound to other exchanges. Internal exchanges are used to
construct wiring that is not visible to applications.
</doc>
</field>
<field name = "nowait" type = "bit">
do not send a reply method
<doc>
If set, the server will not respond to the method. The client should
not wait for a reply method. If the server could not complete the
method it will raise a channel or connection exception.
</doc>
</field>
<field name="arguments" type="table">
arguments for declaration
<doc>
A set of arguments for the declaration. The syntax and semantics
of these arguments depends on the server implementation. This
field is ignored if passive is 1.
</doc>
</field>
</method>
<method name="declare-ok" synchronous="1" index="11">
confirms an exchange declaration
<doc>
This method confirms a Declare method and confirms the name of the
exchange, essential for automatically-named exchanges.
</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="delete" synchronous="1" index="20">
delete an exchange
<doc>
This method deletes an exchange. When an exchange is deleted all queue
bindings on the exchange are cancelled.
</doc>
<chassis name="server" implement="MUST"/>
<response name="delete-ok"/>
<field name="ticket" domain="access ticket">
<rule implement="MUST">
The client MUST provide a valid access ticket giving "active"
access rights to the exchange's access realm.
</rule>
</field>
<field name="exchange" domain="exchange name">
<rule implement="MUST">
<test>amq_exchange_11</test>
The exchange MUST exist. Attempting to delete a non-existing exchange
causes a channel exception.
</rule>
<assert check="notnull"/>
</field>
<field name="if unused" type="bit">
delete only if unused
<doc>
If set, the server will only delete the exchange if it has no queue
bindings. If the exchange has queue bindings the server does not
delete it but raises a channel exception instead.
</doc>
<rule implement="SHOULD">
<test>amq_exchange_12</test>
If set, the server SHOULD delete the exchange but only if it has
no queue bindings.
</rule>
<rule implement="SHOULD">
<test>amq_exchange_13</test>
If set, the server SHOULD raise a channel exception if the exchange is in
use.
</rule>
</field>
<field name = "nowait" type = "bit">
do not send a reply method
<doc>
If set, the server will not respond to the method. The client should
not wait for a reply method. If the server could not complete the
method it will raise a channel or connection exception.
</doc>
</field>
</method>
<method name="delete-ok" synchronous="1" index="21">
confirm deletion of an exchange
<doc>
This method confirms the deletion of an exchange.
</doc>
<chassis name="client" implement="MUST"/>
</method>
</class>
<class name="queue" handler="channel" index="50">
<!--
======================================================
== QUEUES
======================================================
-->
work with queues
<doc>
Queues store and forward messages. Queues can be configured in the server
or created at runtime. Queues must be attached to at least one exchange
in order to receive messages from publishers.
</doc>
<doc name="grammar">
queue = C:DECLARE S:DECLARE-OK
/ C:BIND S:BIND-OK
/ C:PURGE S:PURGE-OK
/ C:DELETE S:DELETE-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="MUST"/>
<rule implement="MUST">
<test>amq_queue_33</test>
A server MUST allow any content class to be sent to any queue, in any
mix, and queue and delivery these content classes independently. Note
that all methods that fetch content off queues are specific to a given
content class.
</rule>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="declare" synchronous="1" index="10">
declare queue, create if needed
<doc>
This method creates or checks a queue. When creating a new queue
the client can specify various properties that control the durability
of the queue and its contents, and the level of sharing for the queue.
</doc>
<rule implement="MUST">
<test>amq_queue_34</test>
The server MUST create a default binding for a newly-created queue
to the default exchange, which is an exchange of type 'direct'.
</rule>
<rule implement="SHOULD">
<test>amq_queue_35</test>
The server SHOULD support a minimum of 256 queues per virtual host
and ideally, impose no limit except as defined by available resources.
</rule>
<chassis name="server" implement="MUST"/>
<response name="declare-ok"/>
<field name="ticket" domain="access ticket">
<doc>
When a client defines a new queue, this belongs to the access realm
of the ticket used. All further work done with that queue must be
done with an access ticket for the same realm.
</doc>
<doc>
The client provides a valid access ticket giving "active" access
to the realm in which the queue exists or will be created, or
"passive" access if the if-exists flag is set.
</doc>
</field>
<field name="queue" domain="queue name">
<rule implement="MAY">
<test>amq_queue_10</test>
The queue name MAY be empty, in which case the server MUST create
a new queue with a unique generated name and return this to the
client in the Declare-Ok method.
</rule>
<rule implement="MUST">
<test>amq_queue_32</test>
Queue names starting with "amq." are reserved for predeclared and
standardised server queues. If the queue name starts with "amq."
and the passive option is zero, the server MUST raise a connection
exception with reply code 403 (access refused).
</rule>
<assert check="regexp" value="^[a-zA-Z0-9-_.:]*$"/>
</field>
<field name="passive" type="bit">
do not create queue
<doc>
If set, the server will not create the queue. The client can use
this to check whether a queue exists without modifying the server
state.
</doc>
<rule implement="MUST">
<test>amq_queue_05</test>
If set, and the queue does not already exist, the server MUST
respond with a reply code 404 (not found) and raise a channel
exception.
</rule>
</field>
<field name="durable" type="bit">
request a durable queue
<doc>
If set when creating a new queue, the queue will be marked as
durable. Durable queues remain active when a server restarts.
Non-durable queues (transient queues) are purged if/when a
server restarts. Note that durable queues do not necessarily
hold persistent messages, although it does not make sense to
send persistent messages to a transient queue.
share/fixed_amqp0-8.xml view on Meta::CPAN
two actions. The server should equally allow for clients that may
be disconnected prematurely, and wish to re-consume from the same
queue without losing messages. We would recommend a configurable
timeout, with a suitable default value being one minute.
</rule>
<rule implement="MUST">
<test>amq_queue_31</test>
The server MUST ignore the auto-delete field if the queue already
exists.
</rule>
</field>
<field name = "nowait" type = "bit">
do not send a reply method
<doc>
If set, the server will not respond to the method. The client should
not wait for a reply method. If the server could not complete the
method it will raise a channel or connection exception.
</doc>
</field>
<field name="arguments" type="table">
arguments for declaration
<doc>
A set of arguments for the declaration. The syntax and semantics
of these arguments depends on the server implementation. This
field is ignored if passive is 1.
</doc>
</field>
</method>
<method name="declare-ok" synchronous="1" index="11">
confirms a queue definition
<doc>
This method confirms a Declare method and confirms the name of the
queue, essential for automatically-named queues.
</doc>
<chassis name="client" implement="MUST"/>
<field name="queue" domain="queue name">
<doc>
Reports the name of the queue. If the server generated a queue
name, this field contains that name.
</doc>
<assert check="notnull"/>
</field>
<field name="message count" type="long">
number of messages in queue
<doc>
Reports the number of messages in the queue, which will be zero
for newly-created queues.
</doc>
</field>
<field name="consumer count" type="long">
number of consumers
<doc>
Reports the number of active consumers for the queue. Note that
consumers can suspend activity (Channel.Flow) in which case they
do not appear in this count.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="bind" synchronous="1" index="20">
bind queue to an exchange
<doc>
This method binds a queue to an exchange. Until a queue is
bound it will not receive any messages. In a classic messaging
model, store-and-forward queues are bound to a dest exchange
and subscription queues are bound to a dest_wild exchange.
</doc>
<rule implement="MUST">
<test>amq_queue_25</test>
A server MUST allow ignore duplicate bindings - that is, two or
more bind methods for a specific queue, with identical arguments
- without treating these as an error.
</rule>
<rule implement="MUST">
<test>amq_queue_39</test>
If a bind fails, the server MUST raise a connection exception.
</rule>
<rule implement="MUST">
<test>amq_queue_12</test>
The server MUST NOT allow a durable queue to bind to a transient
exchange. If the client attempts this the server MUST raise a
channel exception.
</rule>
<rule implement="SHOULD">
<test>amq_queue_13</test>
Bindings for durable queues are automatically durable and the
server SHOULD restore such bindings after a server restart.
</rule>
<rule implement="MUST">
<test>amq_queue_17</test>
If the client attempts to an exchange that was declared as internal,
the server MUST raise a connection exception with reply code 530
(not allowed).
</rule>
<rule implement="SHOULD">
<test>amq_queue_40</test>
The server SHOULD support at least 4 bindings per queue, and
ideally, impose no limit except as defined by available resources.
</rule>
<chassis name="server" implement="MUST"/>
<response name="bind-ok"/>
<field name="ticket" domain="access ticket">
<doc>
The client provides a valid access ticket giving "active"
access rights to the queue's access realm.
</doc>
</field>
<field name = "queue" domain = "queue name">
<doc>
Specifies the name of the queue to bind. If the queue name is
empty, refers to the current queue for the channel, which is
the last declared queue.
</doc>
<doc name = "rule">
If the client did not previously declare a queue, and the queue
name in this method is empty, the server MUST raise a connection
exception with reply code 530 (not allowed).
</doc>
<doc name = "rule" test = "amq_queue_26">
If the queue does not exist the server MUST raise a channel exception
with reply code 404 (not found).
</doc>
</field>
<field name="exchange" domain="exchange name">
The name of the exchange to bind to.
<rule implement="MUST">
<test>amq_queue_14</test>
If the exchange does not exist the server MUST raise a channel
exception with reply code 404 (not found).
</rule>
</field>
<field name="routing key" type="shortstr">
message routing key
<doc>
Specifies the routing key for the binding. The routing key is
used for routing messages depending on the exchange configuration.
Not all exchanges use a routing key - refer to the specific
exchange documentation. If the routing key is empty and the queue
name is empty, the routing key will be the current queue for the
channel, which is the last declared queue.
</doc>
</field>
<field name = "nowait" type = "bit">
do not send a reply method
<doc>
If set, the server will not respond to the method. The client should
not wait for a reply method. If the server could not complete the
method it will raise a channel or connection exception.
</doc>
</field>
<field name="arguments" type="table">
arguments for binding
<doc>
A set of arguments for the binding. The syntax and semantics of
these arguments depends on the exchange class.
</doc>
</field>
</method>
<method name="bind-ok" synchronous="1" index="21">
confirm bind successful
<doc>
This method confirms that the bind was successful.
</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="unbind" synchronous="1" index="50">
unbind a queue from an exchange
<doc>This method unbinds a queue from an exchange.</doc>
<rule implement="MUST">
If a unbind fails, the server MUST raise a connection exception.
</rule>
<chassis name="server" implement="MUST"/>
<response name="unbind-ok"/>
<field name="ticket" domain="access ticket">
<doc>
The client provides a valid access ticket giving "active"
access rights to the queue's access realm.
</doc>
</field>
<field name="queue" domain="queue name">
<doc>Specifies the name of the queue to unbind.</doc>
</field>
<field name="exchange" domain="exchange name">
<doc>The name of the exchange to unbind from.</doc>
</field>
<field name="routing key" type="shortstr">
routing key of binding
<doc>Specifies the routing key of the binding to unbind.</doc>
</field>
<field name="arguments" type="table">
arguments of binding
<doc>Specifies the arguments of the binding to unbind.</doc>
</field>
</method>
<method name="unbind-ok" synchronous="1" index="51">
confirm unbind successful
<doc>This method confirms that the unbind was successful.</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="purge" synchronous="1" index="30">
purge a queue
<doc>
This method removes all messages from a queue. It does not cancel
consumers. Purged messages are deleted without any formal "undo"
mechanism.
</doc>
<rule implement="MUST">
<test>amq_queue_15</test>
A call to purge MUST result in an empty queue.
</rule>
<rule implement="MUST">
<test>amq_queue_41</test>
On transacted channels the server MUST not purge messages that have
already been sent to a client but not yet acknowledged.
</rule>
<rule implement="MAY">
<test>amq_queue_42</test>
The server MAY implement a purge queue or log that allows system
administrators to recover accidentally-purged messages. The server
SHOULD NOT keep purged messages in the same storage spaces as the
live messages since the volumes of purged messages may get very
large.
</rule>
<chassis name="server" implement="MUST"/>
<response name="purge-ok"/>
<field name="ticket" domain="access ticket">
<doc>
The access ticket must be for the access realm that holds the
queue.
</doc>
<rule implement="MUST">
The client MUST provide a valid access ticket giving "read" access
rights to the queue's access realm. Note that purging a queue is
equivalent to reading all messages and discarding them.
</rule>
</field>
<field name = "queue" domain = "queue name">
<doc>
Specifies the name of the queue to purge. If the queue name is
empty, refers to the current queue for the channel, which is
the last declared queue.
</doc>
<doc name = "rule">
If the client did not previously declare a queue, and the queue
name in this method is empty, the server MUST raise a connection
exception with reply code 530 (not allowed).
</doc>
<doc name = "rule" test = "amq_queue_16">
The queue must exist. Attempting to purge a non-existing queue
causes a channel exception.
</doc>
</field>
<field name = "nowait" type = "bit">
do not send a reply method
( run in 1.722 second using v1.01-cache-2.11-cpan-2398b32b56e )