AnyEvent-RabbitMQ
view release on metacpan or search on metacpan
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<?xml version = "1.0"?>
<!--
WARNING: Modified from the official 0-9-1 specification XML by
the addition of:
confirm.select and confirm.select-ok,
exchange.bind and exchange.bind-ok,
exchange.unbind and exchange.unbind-ok,
basic.nack,
the ability for the Server to send basic.ack, basic.nack and
basic.cancel to the client, and
the un-deprecation of exchange.declare{auto-delete} and exchange.declare{internal}
-->
<!--
Copyright Notice
================
Copyright (c) 2006-2008 Cisco Systems, Credit Suisse, Deutsche Boerse
Systems, Envoy Technologies, Inc., Goldman Sachs, IONA Technologies PLC,
iMatix Corporation, JPMorgan Chase Bank Inc. N.A, Novell, Rabbit
Technologies Ltd., Red Hat, Inc., TWIST Process Innovations Ltd, WS02
Inc. and 29West Inc. All rights reserved.
License
=======
Cisco Systems, Credit Suisse, Deutsche Boerse Systems, Envoy Technologies,
Inc., Goldman Sachs, IONA Technologies PLC, iMatix Corporation, JPMorgan
Chase Bank Inc. N.A, Novell, Rabbit Technologies Ltd., Red Hat, Inc.,
TWIST Process Innovations Ltd, WS02, Inc. and 29West Inc. (collectively,
the "Authors") each hereby grants to you a worldwide, perpetual,
royalty-free, nontransferable, nonexclusive license to (i) copy, display,
distribute and implement the Advanced Messaging Queue Protocol ("AMQP")
Specification and (ii) the Licensed Claims that are held by the Authors,
all for the purpose of implementing the Advanced Messaging Queue Protocol
Specification. Your license and any rights under this Agreement will
terminate immediately without notice from any Author if you bring any
claim, suit, demand, or action related to the Advanced Messaging Queue
Protocol Specification against any Author. Upon termination, you shall
destroy all copies of the Advanced Messaging Queue Protocol Specification
in your possession or control.
As used hereunder, "Licensed Claims" means those claims of a patent or
patent application, throughout the world, excluding design patents and
design registrations, owned or controlled, or that can be sublicensed
without fee and in compliance with the requirements of this Agreement,
by an Author or its affiliates now or at any future time and which would
necessarily be infringed by implementation of the Advanced Messaging
Queue Protocol Specification. A claim is necessarily infringed hereunder
only when it is not possible to avoid infringing it because there is no
plausible non-infringing alternative for implementing the required
portions of the Advanced Messaging Queue Protocol Specification.
Notwithstanding the foregoing, Licensed Claims shall not include any
claims other than as set forth above even if contained in the same patent
as Licensed Claims; or that read solely on any implementations of any
portion of the Advanced Messaging Queue Protocol Specification that are
not required by the Advanced Messaging Queue ProtocolSpecification, or
that, if licensed, would require a payment of royalties by the licensor
to unaffiliated third parties. Moreover, Licensed Claims shall not
include (i) any enabling technologies that may be necessary to make or
use any Licensed Product but are not themselves expressly set forth in
the Advanced Messaging Queue Protocol Specification (e.g., semiconductor
manufacturing technology, compiler technology, object oriented
technology, networking technology, operating system technology, and the
like); or (ii) the implementation of other published standards developed
elsewhere and merely referred to in the body of the Advanced Messaging
Queue Protocol Specification, or (iii) any Licensed Product and any
combinations thereof the purpose or function of which is not required
for compliance with the Advanced Messaging Queue Protocol Specification.
share/fixed_amqp0-9-1.xml view on Meta::CPAN
This method confirms a Channel.Close method and tells the recipient that it is safe
to release resources for the channel.
</doc>
<rule name = "reporting">
<doc>
A peer that detects a socket closure without having received a Channel.Close-Ok
handshake method SHOULD log the error.
</doc>
</rule>
<chassis name = "client" implement = "MUST" />
<chassis name = "server" implement = "MUST" />
</method>
</class>
<!-- == EXCHANGE ========================================================= -->
<class name = "exchange" handler = "channel" index = "40" label = "work with exchanges">
<doc>
Exchanges match and distribute messages across queues. Exchanges can be configured in
the server or declared at runtime.
</doc>
<doc type = "grammar">
exchange = C:DECLARE S:DECLARE-OK
/ C:DELETE S:DELETE-OK
/ C:BIND S:BIND-OK
/ C:UNBIND S:UNBIND-OK
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<rule name = "required-types">
<doc>
The server MUST implement these standard exchange types: fanout, direct.
</doc>
<doc type = "scenario">
Client attempts to declare an exchange with each of these standard types.
</doc>
</rule>
<rule name = "recommended-types">
<doc>
The server SHOULD implement these standard exchange types: topic, headers.
</doc>
<doc type = "scenario">
Client attempts to declare an exchange with each of these standard types.
</doc>
</rule>
<rule name = "required-instances">
<doc>
The server MUST, in each virtual host, pre-declare an exchange instance
for each standard exchange type that it implements, where the name of the
exchange instance, if defined, is "amq." followed by the exchange type name.
</doc>
<doc>
The server MUST, in each virtual host, pre-declare at least two direct
exchange instances: one named "amq.direct", the other with no public name
that serves as a default exchange for Publish methods.
</doc>
<doc type = "scenario">
Client declares a temporary queue and attempts to bind to each required
exchange instance ("amq.fanout", "amq.direct", "amq.topic", and "amq.headers"
if those types are defined).
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST pre-declare a direct exchange with no public name to act as
the default exchange for content Publish methods and for default queue bindings.
</doc>
<doc type = "scenario">
Client checks that the default exchange is active by specifying a queue
binding with no exchange name, and publishing a message with a suitable
routing key but without specifying the exchange name, then ensuring that
the message arrives in the queue correctly.
</doc>
</rule>
<rule name = "default-access">
<doc>
The server MUST NOT allow clients to access the default exchange except
by specifying an empty exchange name in the Queue.Bind and content Publish
methods.
</doc>
</rule>
<rule name = "extensions">
<doc>
The server MAY implement other exchange types as wanted.
</doc>
</rule>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "declare" synchronous = "1" index = "10" label = "verify exchange exists, 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 name = "minimum">
<doc>
The server SHOULD support a minimum of 16 exchanges per virtual host and
ideally, impose no limit except as defined by available resources.
</doc>
<doc type = "scenario">
The client declares as many exchanges as it can until the server reports
an error; the number of exchanges successfully declared must be at least
sixteen.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<response name = "declare-ok" />
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "exchange" domain = "exchange-name">
<rule name = "reserved" on-failure = "access-refused">
<doc>
Exchange names starting with "amq." are reserved for pre-declared and
standardised exchanges. The client MAY declare an exchange starting with
"amq." if the passive option is set, or the exchange already exists.
</doc>
<doc type = "scenario">
The client attempts to declare a non-existing exchange starting with
"amq." and with the passive option set to zero.
</doc>
</rule>
<rule name = "syntax" on-failure = "precondition-failed">
<doc>
The exchange name consists of a non-empty sequence of these characters:
letters, digits, hyphen, underscore, period, or colon.
</doc>
<doc type = "scenario">
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<field name = "passive" domain = "bit" label = "do not create exchange">
<doc>
If set, the server will reply with Declare-Ok if the exchange already
exists with the same name, and raise an error if not. The client can
use this to check whether an exchange exists without modifying the
server state. When set, all other method fields except name and no-wait
are ignored. A declare with both passive and no-wait has no effect.
Arguments are compared for semantic equivalence.
</doc>
<rule name = "not-found">
<doc>
If set, and the exchange does not already exist, the server MUST
raise a channel exception with reply code 404 (not found).
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<rule name = "equivalent">
<doc>
If not set and the exchange exists, the server MUST check that the
existing exchange has the same values for type, durable, and arguments
fields. The server MUST respond with Declare-Ok if the requested
exchange matches these fields, and MUST raise a channel exception if
not.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
<field name = "durable" domain = "bit" label = "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 name = "support">
<doc>
The server MUST support both durable and transient exchanges.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
<field name = "auto-delete" domain = "bit" label = "auto-delete when unused">
<doc>
If set, the exchange is deleted when all queues have
finished using it.
</doc>
<rule name = "amq_exchange_02">
<doc>
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.
</doc>
</rule>
<rule name = "amq_exchange_25">
<doc>
The server MUST ignore the auto-delete field if the
exchange already exists.
</doc>
</rule>
</field>
<field name = "internal" domain = "bit" label = "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 = "no-wait" domain = "no-wait" />
<field name = "arguments" domain = "table" label = "arguments for declaration">
<doc>
A set of arguments for the declaration. The syntax and semantics of these
arguments depends on the server implementation.
</doc>
</field>
</method>
<method name = "declare-ok" synchronous = "1" index = "11" label = "confirm 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" label = "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" />
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "exchange" domain = "exchange-name">
<rule name = "exists" on-failure = "not-found">
<doc>
The client MUST NOT attempt to delete an exchange that does not exist.
</doc>
</rule>
<assert check = "notnull" />
</field>
<field name = "if-unused" domain = "bit" label = "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 name = "in-use" on-failure = "precondition-failed">
<doc>
The server MUST NOT delete an exchange that has bindings on it, if the if-unused
field is true.
</doc>
<doc type = "scenario">
The client declares an exchange, binds a queue to it, then tries to delete it
setting if-unused to true.
</doc>
</rule>
</field>
<field name = "no-wait" domain = "no-wait" />
</method>
<method name = "delete-ok" synchronous = "1" index = "21"
label = "confirm deletion of an exchange">
<doc>This method confirms the deletion of an exchange.</doc>
<chassis name = "client" implement = "MUST" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "bind" synchronous = "1" index = "30"
label = "bind exchange to an exchange">
<doc>This method binds an exchange to an exchange.</doc>
<rule name = "duplicates">
<doc>
A server MUST allow and ignore duplicate bindings - that is,
two or more bind methods for a specific exchanges, with
identical arguments - without treating these as an error.
</doc>
<doc type = "scenario">
A client binds an exchange to an exchange. The client then
repeats the bind (with identical arguments).
</doc>
</rule>
<rule name = "cyclical">
<doc>
A server MUST allow cycles of exchange bindings to be
created including allowing an exchange to be bound to
itself.
</doc>
<doc type = "scenario">
A client declares an exchange and binds it to itself.
</doc>
</rule>
<rule name = "unique">
<doc>
A server MUST not deliver the same message more than once to
a destination exchange, even if the topology of exchanges
and bindings results in multiple (even infinite) routes to
that exchange.
</doc>
<doc type = "scenario">
A client declares an exchange and binds it using multiple
bindings to the amq.topic exchange. The client then
publishes a message to the amq.topic exchange that matches
all the bindings.
</doc>
</rule>
<chassis name = "server" implement = "MUST"/>
<response name = "bind-ok"/>
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1"/>
<field name = "destination" domain = "exchange-name"
label = "name of the destination exchange to bind to">
<doc>Specifies the name of the destination exchange to bind.</doc>
<rule name = "exchange-existence" on-failure = "not-found">
<doc>
A client MUST NOT be allowed to bind a non-existent
destination exchange.
</doc>
<doc type = "scenario">
A client attempts to bind an undeclared exchange to an
exchange.
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST accept a blank exchange name to mean the
default exchange.
</doc>
<doc type = "scenario">
The client declares an exchange and binds a blank exchange
name to it.
</doc>
</rule>
</field>
<field name = "source" domain = "exchange-name"
label = "name of the source exchange to bind to">
<doc>Specifies the name of the source exchange to bind.</doc>
<rule name = "exchange-existence" on-failure = "not-found">
<doc>
A client MUST NOT be allowed to bind a non-existent source
exchange.
</doc>
<doc type = "scenario">
A client attempts to bind an exchange to an undeclared
exchange.
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST accept a blank exchange name to mean the
default exchange.
</doc>
<doc type = "scenario">
The client declares an exchange and binds it to a blank
exchange name.
</doc>
</rule>
</field>
<field name = "routing-key" domain = "shortstr"
label = "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.
</doc>
</field>
<field name = "no-wait" domain = "no-wait"/>
<field name = "arguments" domain = "table"
label = "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="31"
label = "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 = "40"
label = "unbind an exchange from an exchange">
<doc>This method unbinds an exchange from an exchange.</doc>
<rule name = "01">
<doc>If a unbind fails, the server MUST raise a connection exception.</doc>
</rule>
<chassis name = "server" implement = "MUST"/>
<response name = "unbind-ok"/>
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1"/>
<field name = "destination" domain = "exchange-name">
<doc>Specifies the name of the destination exchange to unbind.</doc>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to unbind an exchange that
does not exist from an exchange.
</doc>
<doc type = "scenario">
The client attempts to unbind a non-existent exchange from
an exchange.
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST accept a blank exchange name to mean the
default exchange.
</doc>
<doc type = "scenario">
The client declares an exchange, binds a blank exchange
name to it, and then unbinds a blank exchange name from
it.
</doc>
</rule>
</field>
<field name = "source" domain = "exchange-name">
<doc>Specifies the name of the source exchange to unbind.</doc>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to unbind an exchange from an
exchange that does not exist.
</doc>
<doc type = "scenario">
The client attempts to unbind an exchange from a
non-existent exchange.
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST accept a blank exchange name to mean the
default exchange.
</doc>
<doc type = "scenario">
The client declares an exchange, binds an exchange to a
blank exchange name, and then unbinds an exchange from a
black exchange name.
</doc>
</rule>
</field>
<field name = "routing-key" domain = "shortstr"
label = "routing key of binding">
<doc>Specifies the routing key of the binding to unbind.</doc>
</field>
<field name = "no-wait" domain = "no-wait"/>
<field name = "arguments" domain = "table"
label = "arguments of binding">
<doc>Specifies the arguments of the binding to unbind.</doc>
</field>
</method>
<method name = "unbind-ok" synchronous = "1" index = "51"
label = "confirm unbind successful">
<doc>This method confirms that the unbind was successful.</doc>
<chassis name = "client" implement = "MUST"/>
</method>
</class>
<!-- == QUEUE ============================================================ -->
<class name = "queue" handler = "channel" index = "50" label = "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 type = "grammar">
queue = C:DECLARE S:DECLARE-OK
/ C:BIND S:BIND-OK
/ C:UNBIND S:UNBIND-OK
/ C:PURGE S:PURGE-OK
/ C:DELETE S:DELETE-OK
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "declare" synchronous = "1" index = "10" label = "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 name = "default-binding">
<doc>
The server MUST create a default binding for a newly-declared queue to the
default exchange, which is an exchange of type 'direct' and use the queue
name as the routing key.
</doc>
<doc type = "scenario">
Client declares a new queue, and then without explicitly binding it to an
exchange, attempts to send a message through the default exchange binding,
i.e. publish a message to the empty exchange, with the queue name as routing
key.
</doc>
</rule>
<rule name = "minimum-queues">
<doc>
The server SHOULD support a minimum of 256 queues per virtual host and ideally,
impose no limit except as defined by available resources.
</doc>
<doc type = "scenario">
Client attempts to declare as many queues as it can until the server reports
an error. The resulting count must at least be 256.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<response name = "declare-ok" />
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "queue" domain = "queue-name">
<rule name = "default-name">
<doc>
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.
</doc>
<doc type = "scenario">
Client attempts to declare several queues with an empty name. The client then
verifies that the server-assigned names are unique and different.
</doc>
</rule>
<rule name = "reserved" on-failure = "access-refused">
<doc>
Queue names starting with "amq." are reserved for pre-declared and
standardised queues. The client MAY declare a queue starting with
"amq." if the passive option is set, or the queue already exists.
</doc>
<doc type = "scenario">
The client attempts to declare a non-existing queue starting with
"amq." and with the passive option set to zero.
</doc>
</rule>
<rule name = "syntax" on-failure = "precondition-failed">
<doc>
The queue name can be empty, or a sequence of these characters:
letters, digits, hyphen, underscore, period, or colon.
</doc>
<doc type = "scenario">
The client attempts to declare a queue with an illegal name.
</doc>
</rule>
</field>
<field name = "passive" domain = "bit" label = "do not create queue">
<doc>
If set, the server will reply with Declare-Ok if the queue already
exists with the same name, and raise an error if not. The client can
share/fixed_amqp0-9-1.xml view on Meta::CPAN
requested queue matches these fields, and MUST raise a channel exception
if not.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
<field name = "durable" domain = "bit" label = "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.
</doc>
<rule name = "persistence">
<doc>The server MUST recreate the durable queue after a restart.</doc>
<doc type = "scenario">
Client declares a durable queue. The server is then restarted. The client
then attempts to send a message to the queue. The message should be successfully
delivered.
</doc>
</rule>
<rule name = "types">
<doc>The server MUST support both durable and transient queues.</doc>
<doc type = "scenario">
A client declares two named queues, one durable and one transient.
</doc>
</rule>
</field>
<field name = "exclusive" domain = "bit" label = "request an exclusive queue">
<doc>
Exclusive queues may only be accessed by the current connection, and are
deleted when that connection closes. Passive declaration of an exclusive
queue by other connections are not allowed.
</doc>
<rule name = "types">
<doc>
The server MUST support both exclusive (private) and non-exclusive (shared)
queues.
</doc>
<doc type = "scenario">
A client declares two named queues, one exclusive and one non-exclusive.
</doc>
</rule>
<rule name = "exclusive" on-failure = "resource-locked">
<doc>
The client MAY NOT attempt to use a queue that was declared as exclusive
by another still-open connection.
</doc>
<doc type = "scenario">
One client declares an exclusive queue. A second client on a different
connection attempts to declare, bind, consume, purge, delete, or declare
a queue of the same name.
</doc>
</rule>
</field>
<field name = "auto-delete" domain = "bit" label = "auto-delete queue when unused">
<doc>
If set, the queue is deleted when all consumers have finished using it. The last
consumer can be cancelled either explicitly or because its channel is closed. If
there was no consumer ever on the queue, it won't be deleted. Applications can
explicitly delete auto-delete queues using the Delete method as normal.
</doc>
<rule name = "pre-existence">
<doc>
The server MUST ignore the auto-delete field if the queue already exists.
</doc>
<doc type = "scenario">
Client declares two named queues, one as auto-delete and one explicit-delete.
Client then attempts to declare the two queues using the same names again,
but reversing the value of the auto-delete field in each case. Verify that the
queues still exist with the original auto-delete flag values.
</doc>
</rule>
</field>
<field name = "no-wait" domain = "no-wait" />
<field name = "arguments" domain = "table" label = "arguments for declaration">
<doc>
A set of arguments for the declaration. The syntax and semantics of these
arguments depends on the server implementation.
</doc>
</field>
</method>
<method name = "declare-ok" synchronous = "1" index = "11" label = "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" domain = "message-count" />
<field name = "consumer-count" domain = "long" label = "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" label = "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 direct exchange and subscription queues are bound to a topic
exchange.
</doc>
<rule name = "duplicates">
<doc>
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.
</doc>
<doc type = "scenario">
A client binds a named queue to an exchange. The client then repeats the bind
(with identical arguments).
</doc>
</rule>
<rule name = "unique">
<doc>
A server MUST not deliver the same message more than once to a queue, even if
the queue has multiple bindings that match the message.
</doc>
<doc type = "scenario">
A client declares a named queue and binds it using multiple bindings to the
amq.topic exchange. The client then publishes a message that matches all its
bindings.
</doc>
</rule>
<rule name = "transient-exchange">
<doc>
The server MUST allow a durable queue to bind to a transient exchange.
</doc>
<doc type = "scenario">
A client declares a transient exchange. The client then declares a named durable
queue and then attempts to bind the transient exchange to the durable queue.
</doc>
</rule>
<rule name = "durable-exchange">
<doc>
Bindings of durable queues to durable exchanges are automatically durable
and the server MUST restore such bindings after a server restart.
</doc>
<doc type = "scenario">
A server declares a named durable queue and binds it to a durable exchange. The
server is restarted. The client then attempts to use the queue/exchange combination.
</doc>
</rule>
<rule name = "binding-count">
<doc>
The server SHOULD support at least 4 bindings per queue, and ideally, impose no
limit except as defined by available resources.
</doc>
<doc type = "scenario">
A client declares a named queue and attempts to bind it to 4 different
exchanges.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<response name = "bind-ok" />
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "queue" domain = "queue-name">
<doc>Specifies the name of the queue to bind.</doc>
<rule name = "queue-known" on-failure = "not-found">
<doc>
The client MUST either specify a queue name or have previously declared a
queue on the same channel
</doc>
<doc type = "scenario">
The client opens a channel and attempts to bind an unnamed queue.
</doc>
</rule>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to bind a queue that does not exist.
</doc>
<doc type = "scenario">
The client attempts to bind a non-existent queue.
</doc>
</rule>
</field>
<field name = "exchange" domain = "exchange-name" label = "name of the exchange to bind to">
<rule name = "exchange-existence" on-failure = "not-found">
<doc>
A client MUST NOT be allowed to bind a queue to a non-existent exchange.
</doc>
<doc type = "scenario">
A client attempts to bind an named queue to a undeclared exchange.
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST accept a blank exchange name to mean the default exchange.
</doc>
<doc type = "scenario">
The client declares a queue and binds it to a blank exchange name.
</doc>
</rule>
</field>
<field name = "routing-key" domain = "shortstr" label = "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 queue name
is empty, the server uses the last queue declared on the channel. If the
routing key is also empty, the server uses this queue name for the routing
key as well. If the queue name is provided but the routing key is empty, the
server does the binding with that empty routing key. The meaning of empty
routing keys depends on the exchange implementation.
</doc>
<rule name = "direct-exchange-key-matching">
<doc>
If a message queue binds to a direct exchange using routing key K and a
publisher sends the exchange a message with routing key R, then the message
MUST be passed to the message queue if K = R.
</doc>
</rule>
</field>
<field name = "no-wait" domain = "no-wait" />
<field name = "arguments" domain = "table" label = "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" label = "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" label = "unbind a queue from an exchange">
<doc>This method unbinds a queue from an exchange.</doc>
<rule name = "01">
<doc>If a unbind fails, the server MUST raise a connection exception.</doc>
</rule>
<chassis name="server" implement="MUST"/>
<response name="unbind-ok"/>
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "queue" domain = "queue-name">
<doc>Specifies the name of the queue to unbind.</doc>
<rule name = "queue-known" on-failure = "not-found">
<doc>
The client MUST either specify a queue name or have previously declared a
queue on the same channel
</doc>
<doc type = "scenario">
The client opens a channel and attempts to unbind an unnamed queue.
</doc>
</rule>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to unbind a queue that does not exist.
</doc>
<doc type = "scenario">
The client attempts to unbind a non-existent queue.
</doc>
</rule>
</field>
<field name = "exchange" domain = "exchange-name">
<doc>The name of the exchange to unbind from.</doc>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to unbind a queue from an exchange that
does not exist.
</doc>
<doc type = "scenario">
The client attempts to unbind a queue from a non-existent exchange.
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST accept a blank exchange name to mean the default exchange.
</doc>
<doc type = "scenario">
The client declares a queue and binds it to a blank exchange name.
</doc>
</rule>
</field>
<field name = "routing-key" domain = "shortstr" label = "routing key of binding">
<doc>Specifies the routing key of the binding to unbind.</doc>
</field>
<field name = "arguments" domain = "table" label = "arguments of binding">
<doc>Specifies the arguments of the binding to unbind.</doc>
</field>
</method>
<method name = "unbind-ok" synchronous = "1" index = "51" label = "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" label = "purge a queue">
<doc>
This method removes all messages from a queue which are not awaiting
acknowledgment.
</doc>
<rule name = "02">
<doc>
The server MUST NOT purge messages that have already been sent to a client
but not yet acknowledged.
</doc>
</rule>
<rule name = "03">
<doc>
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.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<response name = "purge-ok" />
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "queue" domain = "queue-name">
<doc>Specifies the name of the queue to purge.</doc>
<rule name = "queue-known" on-failure = "not-found">
<doc>
The client MUST either specify a queue name or have previously declared a
queue on the same channel
</doc>
<doc type = "scenario">
The client opens a channel and attempts to purge an unnamed queue.
</doc>
</rule>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to purge a queue that does not exist.
</doc>
<doc type = "scenario">
The client attempts to purge a non-existent queue.
</doc>
</rule>
</field>
<field name = "no-wait" domain = "no-wait" />
</method>
<method name = "purge-ok" synchronous = "1" index = "31" label = "confirms a queue purge">
<doc>This method confirms the purge of a queue.</doc>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
these messages back to an active queue.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<response name = "delete-ok" />
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "queue" domain = "queue-name">
<doc>Specifies the name of the queue to delete.</doc>
<rule name = "queue-known" on-failure = "not-found">
<doc>
The client MUST either specify a queue name or have previously declared a
queue on the same channel
</doc>
<doc type = "scenario">
The client opens a channel and attempts to delete an unnamed queue.
</doc>
</rule>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to delete a queue that does not exist.
</doc>
<doc type = "scenario">
The client attempts to delete a non-existent queue.
</doc>
</rule>
</field>
<field name = "if-unused" domain = "bit" label = "delete only if unused">
<doc>
If set, the server will only delete the queue if it has no consumers. If the
queue has consumers the server does does not delete it but raises a channel
exception instead.
</doc>
<rule name = "in-use" on-failure = "precondition-failed">
<doc>
The server MUST NOT delete a queue that has consumers on it, if the if-unused
field is true.
</doc>
<doc type = "scenario">
The client declares a queue, and consumes from it, then tries to delete it
setting if-unused to true.
</doc>
</rule>
</field>
<field name = "if-empty" domain = "bit" label = "delete only if empty">
<doc>
If set, the server will only delete the queue if it has no messages.
</doc>
<rule name = "not-empty" on-failure = "precondition-failed">
<doc>
The server MUST NOT delete a queue that has messages on it, if the
if-empty field is true.
</doc>
<doc type = "scenario">
The client declares a queue, binds it and publishes some messages into it,
then tries to delete it setting if-empty to true.
</doc>
</rule>
</field>
<field name = "no-wait" domain = "no-wait" />
</method>
<method name = "delete-ok" synchronous = "1" index = "41" label = "confirm deletion of a queue">
<doc>This method confirms the deletion of a queue.</doc>
<chassis name = "client" implement = "MUST" />
<field name = "message-count" domain = "message-count">
<doc>Reports the number of messages deleted.</doc>
</field>
</method>
</class>
<!-- == BASIC ============================================================ -->
<class name = "basic" handler = "channel" index = "60" label = "work with basic content">
<doc>
The Basic class provides methods that support an industry-standard messaging model.
</doc>
<doc type = "grammar">
basic = C:QOS S:QOS-OK
/ C:CONSUME S:CONSUME-OK
/ C:CANCEL S:CANCEL-OK
/ C:PUBLISH content
/ S:RETURN content
/ S:DELIVER content
/ C:GET ( S:GET-OK content / S:GET-EMPTY )
/ C:ACK
/ S:ACK
/ C:REJECT
/ C:NACK
/ S:NACK
/ C:RECOVER-ASYNC
/ C:RECOVER S:RECOVER-OK
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MAY" />
<rule name = "01">
<doc>
The server SHOULD respect the persistent property of basic messages and
SHOULD make a best-effort to hold persistent basic messages on a reliable
storage mechanism.
</doc>
<doc type = "scenario">
Send a persistent message to queue, stop server, restart server and then
verify whether message is still present. Assumes that queues are durable.
Persistence without durable queues makes no sense.
</doc>
</rule>
<rule name = "02">
share/fixed_amqp0-9-1.xml view on Meta::CPAN
If the queue does not exist the server MUST ignore the cancel method, so
long as the consumer tag is valid for that channel.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "SHOULD" />
<response name = "cancel-ok" />
<field name = "consumer-tag" domain = "consumer-tag" />
<field name = "no-wait" domain = "no-wait" />
</method>
<method name = "cancel-ok" synchronous = "1" index = "31" label = "confirm a cancelled consumer">
<doc>
This method confirms that the cancellation was completed.
</doc>
<chassis name = "client" implement = "MUST" />
<chassis name = "server" implement = "MAY" />
<field name = "consumer-tag" domain = "consumer-tag" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "publish" content = "1" index = "40" label = "publish a message">
<doc>
This method publishes a message to a specific exchange. The message will be routed
to queues as defined by the exchange configuration and distributed to any active
consumers when the transaction, if any, is committed.
</doc>
<chassis name = "server" implement = "MUST" />
<!-- Deprecated: "ticket", must be zero -->
<field name = "reserved-1" type = "short" reserved = "1" />
<field name = "exchange" domain = "exchange-name">
<doc>
Specifies the name of the exchange to publish to. The exchange name can be
empty, meaning the default exchange. If the exchange name is specified, and that
exchange does not exist, the server will raise a channel exception.
</doc>
<rule name = "must-exist" on-failure = "not-found">
<doc>
The client MUST NOT attempt to publish a content to an exchange that
does not exist.
</doc>
<doc type = "scenario">
The client attempts to publish a content to a non-existent exchange.
</doc>
</rule>
<rule name = "default-exchange">
<doc>
The server MUST accept a blank exchange name to mean the default exchange.
</doc>
<doc type = "scenario">
The client declares a queue and binds it to a blank exchange name.
</doc>
</rule>
<rule name = "02">
<doc>
If the exchange was declared as an internal exchange, the server MUST raise
a channel exception with a reply code 403 (access refused).
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<rule name = "03">
<doc>
The exchange MAY refuse basic content in which case it MUST raise a channel
exception with reply code 540 (not implemented).
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
<field name = "routing-key" domain = "shortstr" label = "Message routing key">
<doc>
Specifies the routing key for the message. The routing key is used for routing
messages depending on the exchange configuration.
</doc>
</field>
<field name = "mandatory" domain = "bit" label = "indicate mandatory routing">
<doc>
This flag tells the server how to react if the message cannot be routed to a
queue. If this flag is set, the server will return an unroutable message with a
Return method. If this flag is zero, the server silently drops the message.
</doc>
<rule name = "01">
<doc>
The server SHOULD implement the mandatory flag.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
</field>
<field name = "immediate" domain = "bit" label = "request immediate delivery">
<doc>
This flag tells the server how to react if the message cannot be routed to a
queue consumer immediately. If this flag is set, the server will return an
undeliverable message with a Return method. If this flag is zero, the server
will queue the message, but with no guarantee that it will ever be consumed.
</doc>
<rule name = "01">
<doc>
The server SHOULD implement the immediate flag.
</doc>
<doc type = "scenario">
( run in 0.658 second using v1.01-cache-2.11-cpan-2398b32b56e )