AnyEvent-RabbitMQ
view release on metacpan or search on metacpan
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<field name = "frame-max" domain = "long" label = "negotiated maximum frame size">
<doc>
The largest frame size that the client and server will use for the connection.
Zero means that the client does not impose any specific limit but may reject
very large frames if it cannot allocate resources for them. Note that the
frame-max limit applies principally to content frames, where large contents can
be broken into frames of arbitrary size.
</doc>
<rule name = "minimum">
<doc>
Until the frame-max has been negotiated, both peers MUST accept frames of up
to frame-min-size octets large, and the minimum negotiated value for frame-max
is also frame-min-size.
</doc>
</rule>
<rule name = "upper-limit">
<doc>
If the client specifies a frame max that is higher than the value provided
by the server, the server MUST close the connection without attempting a
negotiated close. The server may report the error in some fashion to assist
implementors.
</doc>
</rule>
</field>
<field name = "heartbeat" domain = "short" label = "desired heartbeat delay">
<doc>
The delay, in seconds, of the connection heartbeat that the client wants. Zero
means the client does not want a heartbeat.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "open" synchronous = "1" index = "40" label = "open connection to virtual host">
<doc>
This method opens a connection to a virtual host, which is a collection of
resources, and acts to separate multiple application domains within a server.
The server may apply arbitrary limits per virtual host, such as the number
of each type of entity that may be used, per connection and/or in total.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "open-ok" />
<field name = "virtual-host" domain = "path" label = "virtual host name">
<doc>
The name of the virtual host to work with.
</doc>
<rule name = "separation">
<doc>
If the server supports multiple virtual hosts, it MUST enforce a full
separation of exchanges, queues, and all associated entities per virtual
host. An application, connected to a specific virtual host, MUST NOT be able
to access resources of another virtual host.
</doc>
</rule>
<rule name = "security">
<doc>
The server SHOULD verify that the client has permission to access the
specified virtual host.
</doc>
</rule>
</field>
<!-- Deprecated: "capabilities", must be zero -->
<field name = "reserved-1" type = "shortstr" reserved = "1" />
<!-- Deprecated: "insist", must be zero -->
<field name = "reserved-2" type = "bit" reserved = "1" />
</method>
<method name = "open-ok" synchronous = "1" index = "41" label = "signal that connection is ready">
<doc>
This method signals to the client that the connection is ready for use.
</doc>
<chassis name = "client" implement = "MUST" />
<!-- Deprecated: "known-hosts", must be zero -->
<field name = "reserved-1" type = "shortstr" reserved = "1" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "close" synchronous = "1" index = "50" label = "request a connection close">
<doc>
This method indicates that the sender wants to close the connection. This may be
due to internal conditions (e.g. a forced shut-down) or due to an error handling
a specific method, i.e. an exception. When a close is due to an exception, the
sender provides the class and method id of the method which caused the exception.
</doc>
<rule name = "stability">
<doc>
After sending this method, any received methods except Close and Close-OK MUST
be discarded. The response to receiving a Close after sending Close must be to
send Close-Ok.
</doc>
</rule>
<chassis name = "client" implement = "MUST" />
<chassis name = "server" implement = "MUST" />
<response name = "close-ok" />
<field name = "reply-code" domain = "reply-code" />
<field name = "reply-text" domain = "reply-text" />
<field name = "class-id" domain = "class-id" label = "failing method class">
<doc>
When the close is provoked by a method exception, this is the class of the
method.
</doc>
</field>
<field name = "method-id" domain = "method-id" label = "failing method ID">
<doc>
When the close is provoked by a method exception, this is the ID of the method.
</doc>
</field>
</method>
<method name = "close-ok" synchronous = "1" index = "51" label = "confirm a connection close">
<doc>
This method confirms a Connection.Close method and tells the recipient that it is
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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">
The client attempts to declare an exchange with an illegal name.
</doc>
</rule>
<assert check = "notnull" />
</field>
<field name = "type" domain = "shortstr" label = "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 name = "typed" on-failure = "not-allowed">
<doc>
Exchanges cannot be redeclared with different types. The client MUST not
attempt to redeclare an existing exchange with a different type than used
in the original Exchange.Declare method.
</doc>
<doc type = "scenario">
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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">
<doc>
The server MUST NOT discard a persistent basic message in case of a queue
overflow.
</doc>
<doc type = "scenario">
Declare a queue overflow situation with persistent messages and verify that
messages do not get lost (presumably the server will write them to disk).
</doc>
</rule>
<rule name = "03">
<doc>
The server MAY use the Channel.Flow method to slow or stop a basic message
publisher when necessary.
</doc>
<doc type = "scenario">
Declare a queue overflow situation with non-persistent messages and verify
whether the server responds with Channel.Flow or not. Repeat with persistent
messages.
</doc>
</rule>
<rule name = "04">
<doc>
The server MAY overflow non-persistent basic messages to persistent
storage.
</doc>
<!-- Test scenario: untestable -->
</rule>
<rule name = "05">
<doc>
The server MAY discard or dead-letter non-persistent basic messages on a
priority basis if the queue size exceeds some configured limit.
</doc>
<!-- Test scenario: untestable -->
</rule>
<rule name = "06">
<doc>
The server MUST implement at least 2 priority levels for basic messages,
where priorities 0-4 and 5-9 are treated as two distinct levels.
</doc>
<doc type = "scenario">
Send a number of priority 0 messages to a queue. Send one priority 9
message. Consume messages from the queue and verify that the first message
received was priority 9.
</doc>
</rule>
<rule name = "07">
<doc>
The server MAY implement up to 10 priority levels.
</doc>
<doc type = "scenario">
Send a number of messages with mixed priorities to a queue, so that all
priority values from 0 to 9 are exercised. A good scenario would be ten
messages in low-to-high priority. Consume from queue and verify how many
priority levels emerge.
</doc>
</rule>
<rule name = "08">
<doc>
The server MUST deliver messages of the same priority in order irrespective of
their individual persistence.
</doc>
<doc type = "scenario">
Send a set of messages with the same priority but different persistence
settings to a queue. Consume and verify that messages arrive in same order
as originally published.
</doc>
</rule>
<rule name = "09">
<doc>
The server MUST support un-acknowledged delivery of Basic content, i.e.
consumers with the no-ack field set to TRUE.
</doc>
</rule>
<rule name = "10">
<doc>
The server MUST support explicitly acknowledged delivery of Basic content,
i.e. consumers with the no-ack field set to FALSE.
</doc>
<doc type = "scenario">
Declare a queue and a consumer using explicit acknowledgements. Publish a
set of messages to the queue. Consume the messages but acknowledge only
half of them. Disconnect and reconnect, and consume from the queue.
Verify that the remaining messages are received.
</doc>
</rule>
<!-- These are the properties for a Basic content -->
<!-- MIME typing -->
<field name = "content-type" domain = "shortstr" label = "MIME content type" />
<!-- MIME typing -->
<field name = "content-encoding" domain = "shortstr" label = "MIME content encoding" />
<!-- For applications, and for header exchange routing -->
<field name = "headers" domain = "table" label = "message header field table" />
<!-- For queues that implement persistence -->
<field name = "delivery-mode" domain = "octet" label = "non-persistent (1) or persistent (2)" />
<!-- For queues that implement priorities -->
<field name = "priority" domain = "octet" label = "message priority, 0 to 9" />
<!-- For application use, no formal behaviour -->
<field name = "correlation-id" domain = "shortstr" label = "application correlation identifier" />
<!-- For application use, no formal behaviour but may hold the
name of a private response queue, when used in request messages -->
<field name = "reply-to" domain = "shortstr" label = "address to reply to" />
<!-- For implementation use, no formal behaviour -->
<field name = "expiration" domain = "shortstr" label = "message expiration specification" />
<!-- For application use, no formal behaviour -->
<field name = "message-id" domain = "shortstr" label = "application message identifier" />
<!-- For application use, no formal behaviour -->
<field name = "timestamp" domain = "timestamp" label = "message timestamp" />
<!-- For application use, no formal behaviour -->
<field name = "type" domain = "shortstr" label = "message type name" />
<!-- For application use, no formal behaviour -->
<field name = "user-id" domain = "shortstr" label = "creating user id" />
<!-- For application use, no formal behaviour -->
<field name = "app-id" domain = "shortstr" label = "creating application id" />
<!-- Deprecated, was old cluster-id property -->
<field name = "reserved" domain = "shortstr" label = "reserved, must be empty" />
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "qos" synchronous = "1" index = "10" label = "specify quality of service">
<doc>
( run in 0.754 second using v1.01-cache-2.11-cpan-13bb782fe5a )