AnyEvent-RabbitMQ
view release on metacpan or search on metacpan
{
"abstract" : "An asynchronous and multi channel Perl AMQP client.",
"author" : [
"Masahito Ikuta <cooldaemon@gmail.com>"
],
"dynamic_config" : 0,
"generated_by" : "Dist::Zilla version 6.010, CPAN::Meta::Converter version 2.150010",
"license" : [
"perl_5"
],
"meta-spec" : {
"url" : "http://search.cpan.org/perldoc?CPAN::Meta::Spec",
---
abstract: 'An asynchronous and multi channel Perl AMQP client.'
author:
- 'Masahito Ikuta <cooldaemon@gmail.com>'
build_requires:
Test::Exception: '0'
Test::More: '0'
version: '0.77'
configure_requires:
ExtUtils::MakeMaker: '0'
File::ShareDir::Install: '0.06'
dynamic_config: 0
Makefile.PL view on Meta::CPAN
use ExtUtils::MakeMaker;
use File::ShareDir::Install;
$File::ShareDir::Install::INCLUDE_DOTFILES = 1;
$File::ShareDir::Install::INCLUDE_DOTDIRS = 1;
install_share dist => "share";
my %WriteMakefileArgs = (
"ABSTRACT" => "An asynchronous and multi channel Perl AMQP client.",
"AUTHOR" => "Masahito Ikuta <cooldaemon\@gmail.com>",
"CONFIGURE_REQUIRES" => {
"ExtUtils::MakeMaker" => 0,
"File::ShareDir::Install" => "0.06"
},
"DISTNAME" => "AnyEvent-RabbitMQ",
"LICENSE" => "perl",
"MIN_PERL_VERSION" => "5.010",
"NAME" => "AnyEvent::RabbitMQ",
"PREREQ_PM" => {
This is Perl module AnyEvent::RabbitMQ.
AnyEvent::RabbitMQ is an AMQP(Advanced Message Queuing Protocol) client library, that is intended to allow you to interact with AMQP-compliant message brokers/servers such as RabbitMQ in an asynchronous fashion.
You can use AnyEvent::RabbitMQ to -
* Declare and delete exchanges
* Declare, delete, bind and unbind queues
* Set QoS
* Publish, consume, get, ack, recover and reject messages
* Select, commit and rollback transactions
AnyEvent::RabbitMQ is known to work with RabbitMQ versions 2.5.1 and version 0-8 of the AMQP specification.
lib/AnyEvent/RabbitMQ.pm view on Meta::CPAN
my $self = shift;
$self->close() unless in_global_destruction;
return;
}
1;
__END__
=head1 NAME
AnyEvent::RabbitMQ - An asynchronous and multi channel Perl AMQP client.
=head1 SYNOPSIS
use AnyEvent::RabbitMQ;
my $cv = AnyEvent->condvar;
my $ar = AnyEvent::RabbitMQ->new->load_xml_spec()->connect(
host => 'localhost',
port => 5672,
lib/AnyEvent/RabbitMQ.pm view on Meta::CPAN
else {
die $why;
}
},
);
print $cv->recv, "\n";
=head1 DESCRIPTION
AnyEvent::RabbitMQ is an AMQP(Advanced Message Queuing Protocol) client library, that is intended to allow you to interact with AMQP-compliant message brokers/servers such as RabbitMQ in an asynchronous fashion.
You can use AnyEvent::RabbitMQ to -
* Declare and delete exchanges
* Declare, delete, bind and unbind queues
* Set QoS and confirm mode
* Publish, consume, get, ack, recover and reject messages
* Select, commit and rollback transactions
Most of these actions can be done through L<AnyEvent::RabbitMQ::Channel>.
share/fixed_amqp0-8.xml view on Meta::CPAN
S:TUNE C:TUNE-OK
C:OPEN S:OPEN-OK | S:REDIRECT
challenge = S:SECURE C:SECURE-OK
use-connection = *channel
close-connection = C:CLOSE S:CLOSE-OK
/ S:CLOSE C:CLOSE-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="MUST"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="start" synchronous="1" index="10">
start connection negotiation
<doc>
This method starts the connection negotiation process by telling
the client the protocol version that the server proposes, along
with a list of security mechanisms which the client can use for
authentication.
</doc>
<rule implement="MUST">
If the client cannot handle the protocol version suggested by the
server it MUST close the socket connection.
share/fixed_amqp0-8.xml view on Meta::CPAN
A list of the message locales that the server supports, delimited
by spaces. The locale defines the language in which the server
will send reply texts.
</doc>
<rule implement="MUST">
All servers MUST support at least the en_US locale.
</rule>
<assert check="notnull"/>
</field>
</method>
<method name="start-ok" synchronous="1" index="11">
select security mechanism and locale
<doc>
This method selects a SASL security mechanism. ASL uses SASL
(RFC2222) to negotiate authentication and encryption.
</doc>
<chassis name="server" implement="MUST"/>
<field name="client properties" domain="peer properties">
client properties
</field>
<field name="mechanism" type="shortstr">
share/fixed_amqp0-8.xml view on Meta::CPAN
<field name="locale" type="shortstr">
selected message locale
<doc>
A single message local selected by the client, which must be one
of those specified by the server.
</doc>
<assert check="notnull"/>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="secure" synchronous="1" index="20">
security mechanism challenge
<doc>
The SASL protocol works by exchanging challenges and responses until
both peers have received sufficient information to authenticate each
other. This method challenges the client to provide more information.
</doc>
<chassis name="client" implement="MUST"/>
<response name="secure-ok"/>
<field name="challenge" type="longstr">
security challenge data
<doc>
Challenge information, a block of opaque binary data passed to
the security mechanism.
</doc>
<see name="security mechanisms"/>
</field>
</method>
<method name="secure-ok" synchronous="1" index="21">
security mechanism response
<doc>
This method attempts to authenticate, passing a block of SASL data
for the security mechanism at the server side.
</doc>
<chassis name="server" implement="MUST"/>
<field name="response" type="longstr">
security response data
<doc>
A block of opaque data passed to the security mechanism. The contents
of this data are defined by the SASL security mechanism.
</doc>
<assert check="notnull"/>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="tune" synchronous="1" index="30">
propose connection tuning parameters
<doc>
This method proposes a set of connection configuration values
to the client. The client can accept and/or adjust these.
</doc>
<chassis name="client" implement="MUST"/>
<response name="tune-ok"/>
<field name="channel max" type="short">
proposed maximum channels
<doc>
share/fixed_amqp0-8.xml view on Meta::CPAN
</rule>
</field>
<field name="heartbeat" type="short">
desired heartbeat delay
<doc>
The delay, in seconds, of the connection heartbeat that the server
wants. Zero means the server does not want a heartbeat.
</doc>
</field>
</method>
<method name="tune-ok" synchronous="1" index="31">
negotiate connection tuning parameters
<doc>
This method sends the client's connection tuning parameters to the
server. Certain fields are negotiated, others provide capability
information.
</doc>
<chassis name="server" implement="MUST"/>
<field name="channel max" type="short">
negotiated maximum channels
<doc>
share/fixed_amqp0-8.xml view on Meta::CPAN
</field>
<field name="heartbeat" type="short">
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">
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.
</doc>
<rule implement="MUST">
The client MUST open the context before doing any work on the
connection.
</rule>
share/fixed_amqp0-8.xml view on Meta::CPAN
may respond to a Connection.Open method with a Connection.Redirect.
The insist option tells the server that the client is insisting on
a connection to the specified server.
</doc>
<rule implement="SHOULD">
When the client uses the insist option, the server SHOULD accept
the client connection unless it is technically unable to do so.
</rule>
</field>
</method>
<method name="open-ok" synchronous="1" index="41">
signal that the connection is ready
<doc>
This method signals to the client that the connection is ready for
use.
</doc>
<chassis name="client" implement="MUST"/>
<field name="known hosts" domain="known hosts"/>
</method>
<method name="redirect" synchronous="1" index="50">
asks the client to use a different server
<doc>
This method redirects the client to another server, based on the
requested virtual host and/or capabilities.
</doc>
<rule implement="SHOULD">
When getting the Connection.Redirect method, the client SHOULD
reconnect to the host specified, and if that host is not present,
to any of the hosts specified in the known-hosts list.
</rule>
share/fixed_amqp0-8.xml view on Meta::CPAN
Specifies the server to connect to. This is an IP address or a
DNS name, optionally followed by a colon and a port number. If
no port number is specified, the client should use the default
port number for the protocol.
</doc>
<assert check="notnull"/>
</field>
<field name="known hosts" domain="known hosts"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="close" synchronous="1" index="60">
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 implement="MUST">
After sending this method any received method except the Close-OK
share/fixed_amqp0-8.xml view on Meta::CPAN
</doc>
</field>
<field name="method id" domain="class id">
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="61">
confirm a connection close
<doc>
This method confirms a Connection.Close method and tells the
recipient that it is safe to release resources for the connection
and close the socket.
</doc>
<rule implement="SHOULD">
A peer that detects a socket closure without having received a
Close-Ok handshake method SHOULD log the error.
</rule>
share/fixed_amqp0-8.xml view on Meta::CPAN
use-channel = C:FLOW S:FLOW-OK
/ S:FLOW C:FLOW-OK
/ S:ALERT
/ functional-class
close-channel = C:CLOSE S:CLOSE-OK
/ S:CLOSE C:CLOSE-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="MUST"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="open" synchronous="1" index="10">
open a channel for use
<doc>
This method opens a virtual connection (a channel).
</doc>
<rule implement="MUST">
This method MUST NOT be called when the channel is already open.
</rule>
<chassis name="server" implement="MUST"/>
<response name="open-ok"/>
<field name="out of band" type="shortstr">
out-of-band settings
<doc>
Configures out-of-band transfers on this channel. The syntax and
meaning of this field will be formally defined at a later date.
</doc>
<assert check="null"/>
</field>
</method>
<method name="open-ok" synchronous="1" index="11">
signal that the channel is ready
<doc>
This method signals to the client that the channel is ready for use.
</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="flow" synchronous="1" index="20">
enable/disable flow from peer
<doc>
This method asks the peer to pause or restart the flow of content
data. This is a simple flow-control mechanism that a peer can use
to avoid oveflowing its queues or otherwise finding itself receiving
more messages than it can process. Note that this method is not
intended for window control. The peer that receives a request to
stop sending content should finish sending the current content, if
any, and then wait until it receives a Flow restart method.
</doc>
share/fixed_amqp0-8.xml view on Meta::CPAN
peer will start sending or continue to send content frames; 0
means it will not.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="alert" index="30">
send a non-fatal warning message
<doc>
This method allows the server to send a non-fatal warning to the
client. This is used for methods that are normally asynchronous
and thus do not have confirmations, and for which the server may
detect errors that need to be reported. Fatal errors are handled
as channel or connection exceptions; non-fatal errors are sent
through this method.
</doc>
<chassis name="client" implement="MUST"/>
<field name="reply code" domain="reply code"/>
<field name="reply text" domain="reply text"/>
<field name="details" type="table">
detailed information for warning
<doc>
A set of fields that provide more information about the
problem. The meaning of these fields are defined on a
per-reply-code basis (TO BE DEFINED).
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="close" synchronous="1" index="40">
request a channel close
<doc>
This method indicates that the sender wants to close the channel.
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 implement="MUST">
After sending this method any received method except
share/fixed_amqp0-8.xml view on Meta::CPAN
</doc>
</field>
<field name="method id" domain="method id">
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="41">
confirm a channel close
<doc>
This method confirms a Channel.Close method and tells the recipient
that it is safe to release resources for the channel and close the
socket.
</doc>
<rule implement="SHOULD">
A peer that detects a socket closure without having received a
Channel.Close-Ok handshake method SHOULD log the error.
</rule>
share/fixed_amqp0-8.xml view on Meta::CPAN
A client must explicitly request access tickets before doing work.
An access ticket grants a client the right to use a specific set of
resources - called a "realm" - in specific ways.
</doc>
<doc name="grammar">
access = C:REQUEST S:REQUEST-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="MUST"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="request" synchronous="1" index="10">
request an access ticket
<doc>
This method requests an access ticket for an access realm.
The server responds by granting the access ticket. If the
client does not have access rights to the requested realm
this causes a connection exception. Access tickets are a
per-channel resource.
</doc>
<rule implement="MUST">
The realm name MUST start with either "/data" (for application
share/fixed_amqp0-8.xml view on Meta::CPAN
</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>
share/fixed_amqp0-8.xml view on Meta::CPAN
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>
share/fixed_amqp0-8.xml view on Meta::CPAN
<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"
share/fixed_amqp0-8.xml view on Meta::CPAN
<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">
<!--
======================================================
share/fixed_amqp0-8.xml view on Meta::CPAN
<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'.
share/fixed_amqp0-8.xml view on Meta::CPAN
<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.
share/fixed_amqp0-8.xml view on Meta::CPAN
<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
share/fixed_amqp0-8.xml view on Meta::CPAN
</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>
share/fixed_amqp0-8.xml view on Meta::CPAN
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>
share/fixed_amqp0-8.xml view on Meta::CPAN
<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="purge-ok" synchronous="1" index="31">
confirms a queue purge
<doc>
This method confirms the purge of a queue.
</doc>
<chassis name="client" implement="MUST"/>
<field name="message count" type="long">
number of messages purged
<doc>
Reports the number of messages purged.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="delete" synchronous="1" index="40">
delete a queue
<doc>
This method deletes a queue. When a queue is deleted any pending
messages are sent to a dead-letter queue if this is defined in the
server configuration, and all consumers on the queue are cancelled.
</doc>
<rule implement="SHOULD">
<test>amq_queue_43</test>
The server SHOULD use a dead-letter queue to hold messages that
were pending on a deleted queue, and MAY provide facilities for
share/fixed_amqp0-8.xml view on Meta::CPAN
<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="41">
confirm deletion of a queue
<doc>
This method confirms the deletion of a queue.
</doc>
<chassis name="client" implement="MUST"/>
<field name="message count" type="long">
number of messages purged
<doc>
Reports the number of messages purged.
</doc>
share/fixed_amqp0-8.xml view on Meta::CPAN
<field name = "app id" type = "shortstr">
The creating application id
</field>
<field name = "cluster id" type = "shortstr">
Intra-cluster routing identifier
</field>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "qos" synchronous = "1" index = "10">
specify quality of service
<doc>
This method requests a specific quality of service. The QoS can
be specified for the current channel or for all channels on the
connection. The particular properties and semantics of a qos method
always depend on the content class semantics. Though the qos method
could in principle apply to both peers, it is currently meaningful
only for the server.
</doc>
<chassis name = "server" implement = "MUST" />
share/fixed_amqp0-8.xml view on Meta::CPAN
<field name = "global" type = "bit">
apply to entire connection
<doc>
By default the QoS settings apply to the current channel only. If
this field is set, they are applied to the entire connection.
</doc>
</field>
</method>
<method name = "qos-ok" synchronous = "1" index = "11">
confirm the requested qos
<doc>
This method tells the client that the requested QoS levels could
be handled by the server. The requested QoS applies to all active
consumers until a new QoS is defined.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "consume" synchronous = "1" index = "20">
start a queue consumer
<doc>
This method asks the server to start a "consumer", which is a
transient request for messages from a specific queue. Consumers
last as long as the channel they were created on, or until the
client cancels them.
</doc>
<doc name = "rule" test = "amq_basic_01">
The server SHOULD support at least 16 consumers per queue, unless
the queue was declared as private, and ideally, impose no limit
share/fixed_amqp0-8.xml view on Meta::CPAN
<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 = "consume-ok" synchronous = "1" index = "21">
confirm a new consumer
<doc>
The server provides the client with a consumer tag, which is used
by the client for methods called on the consumer at a later stage.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer tag" domain = "consumer tag">
<doc>
Holds the consumer tag specified by the client or provided by
the server.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "cancel" synchronous = "1" index = "30">
end a queue consumer
<doc test = "amq_basic_04">
This method cancels a consumer. This does not affect already
delivered messages, but it does mean the server will not send any
more messages for that consumer. The client may receive an
abitrary number of messages in between sending the cancel method
and receiving the cancel-ok reply.
</doc>
<doc name = "rule" test = "todo">
If the queue no longer exists when the client sends a cancel command,
share/fixed_amqp0-8.xml view on Meta::CPAN
<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 = "cancel-ok" synchronous = "1" index = "31">
confirm a cancelled consumer
<doc>
This method confirms that the cancellation was completed.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer tag" domain = "consumer tag" />
</method>
share/fixed_amqp0-8.xml view on Meta::CPAN
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "deliver" content = "1" index = "60">
notify the client of a consumer message
<doc>
This method delivers a message to the client, via a consumer. In
the asynchronous message delivery model, the client starts a
consumer using the Consume method, then the server responds with
Deliver methods as and when messages arrive for that consumer.
</doc>
<doc name = "rule" test = "amq_basic_19">
The server SHOULD track the number of times a message has been
delivered to clients and when a message is redelivered a certain
number of times - e.g. 5 times - without being acknowledged, the
server SHOULD consider the message to be unprocessable (possibly
causing client applications to abort), and move the message to a
dead letter queue.
share/fixed_amqp0-8.xml view on Meta::CPAN
<doc>
Specifies the routing key name specified when the message was
published.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "get" synchronous = "1" index = "70">
direct access to a queue
<doc>
This method provides a direct access to the messages in a queue
using a synchronous dialogue that is designed for specific types of
application where synchronous functionality is more important than
performance.
</doc>
<response name = "get-ok" />
<response name = "get-empty" />
<chassis name = "server" implement = "MUST" />
<field name = "ticket" domain = "access ticket">
<doc name = "rule">
The client MUST provide a valid access ticket giving "read"
access rights to the realm for the queue.
share/fixed_amqp0-8.xml view on Meta::CPAN
<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>
</field>
<field name = "no ack" domain = "no ack" />
</method>
<method name = "get-ok" synchronous = "1" content = "1" index = "71">
provide client with a message
<doc>
This method delivers a message to the client following a get
method. A message delivered by 'get-ok' must be acknowledged
unless the no-ack option was set in the get method.
</doc>
<chassis name = "client" implement = "MAY" />
<field name = "delivery tag" domain = "delivery tag" />
share/fixed_amqp0-8.xml view on Meta::CPAN
<doc>
This field reports the number of messages pending on the queue,
excluding the message being delivered. Note that this figure is
indicative, not reliable, and can change arbitrarily as messages
are added to the queue and removed by other clients.
</doc>
</field>
</method>
<method name = "get-empty" synchronous = "1" index = "72">
indicate no messages available
<doc>
This method tells the client that the queue has no messages
available for the client.
</doc>
<chassis name = "client" implement = "MAY" />
<field name = "cluster id" type = "shortstr">
Cluster id
<doc>
share/fixed_amqp0-8.xml view on Meta::CPAN
<field name = "timestamp" type = "timestamp">
The message timestamp
</field>
<field name = "cluster id" type = "shortstr">
Intra-cluster routing identifier
</field>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "qos" synchronous = "1" index = "10">
specify quality of service
<doc>
This method requests a specific quality of service. The QoS can
be specified for the current channel or for all channels on the
connection. The particular properties and semantics of a qos method
always depend on the content class semantics. Though the qos method
could in principle apply to both peers, it is currently meaningful
only for the server.
</doc>
<chassis name = "server" implement = "MUST" />
share/fixed_amqp0-8.xml view on Meta::CPAN
<field name = "global" type = "bit">
apply to entire connection
<doc>
By default the QoS settings apply to the current channel only. If
this field is set, they are applied to the entire connection.
</doc>
</field>
</method>
<method name = "qos-ok" synchronous = "1" index = "11">
confirm the requested qos
<doc>
This method tells the client that the requested QoS levels could
be handled by the server. The requested QoS applies to all active
consumers until a new QoS is defined.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "consume" synchronous = "1" index = "20">
start a queue consumer
<doc>
This method asks the server to start a "consumer", which is a
transient request for messages from a specific queue. Consumers
last as long as the channel they were created on, or until the
client cancels them.
</doc>
<doc name = "rule">
The server SHOULD support at least 16 consumers per queue, unless
the queue was declared as private, and ideally, impose no limit
share/fixed_amqp0-8.xml view on Meta::CPAN
<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 = "consume-ok" synchronous = "1" index = "21">
confirm a new consumer
<doc>
This method provides the client with a consumer tag which it MUST
use in methods that work with the consumer.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer tag" domain = "consumer tag">
<doc>
Holds the consumer tag specified by the client or provided by
the server.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "cancel" synchronous = "1" index = "30">
end a queue consumer
<doc>
This method cancels a consumer. This does not affect already
delivered messages, but it does mean the server will not send any
more messages for that consumer.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "cancel-ok" />
<field name = "consumer tag" domain = "consumer tag" />
share/fixed_amqp0-8.xml view on Meta::CPAN
<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 = "cancel-ok" synchronous = "1" index = "31">
confirm a cancelled consumer
<doc>
This method confirms that the cancellation was completed.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer tag" domain = "consumer tag" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "open" synchronous = "1" index = "40">
request to start staging
<doc>
This method requests permission to start staging a message. Staging
means sending the message into a temporary area at the recipient end
and then delivering the message by referring to this temporary area.
Staging is how the protocol handles partial file transfers - if a
message is partially staged and the connection breaks, the next time
the sender starts to stage it, it can restart from where it left off.
</doc>
<response name = "open-ok" />
share/fixed_amqp0-8.xml view on Meta::CPAN
information to allocate or check available space in advance, to
avoid "disk full" errors during staging of very large messages.
</doc>
<doc name = "rule">
The sender MUST accurately fill the content-size field.
Zero-length content is permitted.
</doc>
</field>
</method>
<method name = "open-ok" synchronous = "1" index = "41">
confirm staging ready
<doc>
This method confirms that the recipient is ready to accept staged
data. If the message was already partially-staged at a previous
time the recipient will report the number of octets already staged.
</doc>
<response name = "stage" />
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
share/fixed_amqp0-8.xml view on Meta::CPAN
<doc name = "rule" test = "amq_file_00">
The server SHOULD implement the immediate flag.
</doc>
</field>
<field name = "identifier" type = "shortstr">
staging identifier
<doc>
This is the staging identifier of the message to publish. The
message must have been staged. Note that a client can send the
Publish method asynchronously without waiting for staging to
finish.
</doc>
</field>
</method>
<method name = "return" content = "1" index = "70">
return a failed message
<doc>
This method returns an undeliverable message that was published
with the "immediate" flag set, or an unroutable message published
share/fixed_amqp0-8.xml view on Meta::CPAN
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "deliver" index = "80">
notify the client of a consumer message
<doc>
This method delivers a staged file message to the client, via a
consumer. In the asynchronous message delivery model, the client
starts a consumer using the Consume method, then the server
responds with Deliver methods as and when messages arrive for
that consumer.
</doc>
<doc name = "rule">
The server SHOULD track the number of times a message has been
delivered to clients and when a message is redelivered a certain
number of times - e.g. 5 times - without being acknowledged, the
server SHOULD consider the message to be unprocessable (possibly
causing client applications to abort), and move the message to a
share/fixed_amqp0-8.xml view on Meta::CPAN
Specifies the routing key name specified when the message was
published.
</doc>
</field>
<field name = "identifier" type = "shortstr">
staging identifier
<doc>
This is the staging identifier of the message to deliver. The
message must have been staged. Note that a server can send the
Deliver method asynchronously without waiting for staging to
finish.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "ack" index = "90">
acknowledge one or more messages
share/fixed_amqp0-8.xml view on Meta::CPAN
<field name = "priority" type = "octet">
The message priority, 0 to 9
</field>
<field name = "timestamp" type = "timestamp">
The message timestamp
</field>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "qos" synchronous = "1" index = "10">
specify quality of service
<doc>
This method requests a specific quality of service. The QoS can
be specified for the current channel or for all channels on the
connection. The particular properties and semantics of a qos method
always depend on the content class semantics. Though the qos method
could in principle apply to both peers, it is currently meaningful
only for the server.
</doc>
<chassis name = "server" implement = "MUST" />
share/fixed_amqp0-8.xml view on Meta::CPAN
<field name = "global" type = "bit">
apply to entire connection
<doc>
By default the QoS settings apply to the current channel only. If
this field is set, they are applied to the entire connection.
</doc>
</field>
</method>
<method name = "qos-ok" synchronous = "1" index = "11">
confirm the requested qos
<doc>
This method tells the client that the requested QoS levels could
be handled by the server. The requested QoS applies to all active
consumers until a new QoS is defined.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "consume" synchronous = "1" index = "20">
start a queue consumer
<doc>
This method asks the server to start a "consumer", which is a
transient request for messages from a specific queue. Consumers
last as long as the channel they were created on, or until the
client cancels them.
</doc>
<doc name = "rule">
The server SHOULD support at least 16 consumers per queue, unless
the queue was declared as private, and ideally, impose no limit
share/fixed_amqp0-8.xml view on Meta::CPAN
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 = "consume-ok" synchronous = "1" index = "21">
confirm a new consumer
<doc>
This method provides the client with a consumer tag which it may
use in methods that work with the consumer.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer tag" domain = "consumer tag">
<doc>
Holds the consumer tag specified by the client or provided by
the server.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "cancel" synchronous = "1" index = "30">
end a queue consumer
<doc>
This method cancels a consumer. Since message delivery is
asynchronous the client may continue to receive messages for
a short while after canceling a consumer. It may process or
discard these as appropriate.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "cancel-ok" />
<field name = "consumer tag" domain = "consumer tag" />
<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 = "cancel-ok" synchronous = "1" index = "31">
confirm a cancelled consumer
<doc>
This method confirms that the cancellation was completed.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer tag" domain = "consumer tag" />
</method>
share/fixed_amqp0-8.xml view on Meta::CPAN
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "deliver" content = "1" index = "60">
notify the client of a consumer message
<doc>
This method delivers a message to the client, via a consumer. In
the asynchronous message delivery model, the client starts a
consumer using the Consume method, then the server responds with
Deliver methods as and when messages arrive for that consumer.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer tag" domain = "consumer tag" />
<field name = "delivery tag" domain = "delivery tag" />
<field name = "exchange" domain = "exchange name">
share/fixed_amqp0-8.xml view on Meta::CPAN
the application layer.
</rule>
<doc name="grammar">
tx = C:SELECT S:SELECT-OK
/ C:COMMIT S:COMMIT-OK
/ C:ROLLBACK S:ROLLBACK-OK
</doc>
<chassis name="server" implement="SHOULD"/>
<chassis name="client" implement="MAY"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="select" synchronous="1" index="10">
select standard transaction mode
<doc>
This method sets the channel to use standard transactions. The
client must use this method at least once on a channel before
using the Commit or Rollback methods.
</doc>
<chassis name="server" implement="MUST"/>
<response name="select-ok"/>
</method>
<method name="select-ok" synchronous="1" index="11">
confirm transaction mode
<doc>
This method confirms to the client that the channel was successfully
set to use standard transactions.
</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="commit" synchronous="1" index="20">
commit the current transaction
<doc>
This method commits all messages published and acknowledged in
the current transaction. A new transaction starts immediately
after a commit.
</doc>
<chassis name="server" implement="MUST"/>
<response name="commit-ok"/>
</method>
<method name="commit-ok" synchronous="1" index="21">
confirm a successful commit
<doc>
This method confirms to the client that the commit succeeded.
Note that if a commit fails, the server raises a channel exception.
</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="rollback" synchronous="1" index="30">
abandon the current transaction
<doc>
This method abandons all messages published and acknowledged in
the current transaction. A new transaction starts immediately
after a rollback.
</doc>
<chassis name="server" implement="MUST"/>
<response name="rollback-ok"/>
</method>
<method name="rollback-ok" synchronous="1" index="31">
confirm a successful rollback
<doc>
This method confirms to the client that the rollback succeeded.
Note that if an rollback fails, the server raises a channel exception.
</doc>
<chassis name="client" implement="MUST"/>
</method>
</class>
<class name="dtx" handler="channel" index="100">
<!--
share/fixed_amqp0-8.xml view on Meta::CPAN
The Dtx class assumes that the server has a private communications
channel (not AMQP) to a distributed transaction coordinator.
</doc>
<doc name="grammar">
dtx = C:SELECT S:SELECT-OK
C:START S:START-OK
</doc>
<chassis name="server" implement="MAY"/>
<chassis name="client" implement="MAY"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="select" synchronous="1" index="10">
select standard transaction mode
<doc>
This method sets the channel to use distributed transactions. The
client must use this method at least once on a channel before
using the Start method.
</doc>
<chassis name="server" implement="MUST"/>
<response name="select-ok"/>
</method>
<method name="select-ok" synchronous="1" index="11">
confirm transaction mode
<doc>
This method confirms to the client that the channel was successfully
set to use distributed transactions.
</doc>
<chassis name="client" implement="MUST"/>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="start" synchronous="1" index="20">
start a new distributed transaction
<doc>
This method starts a new distributed transaction. This must be
the first method on a new channel that uses the distributed
transaction mode, before any methods that publish or consume
messages.
</doc>
<chassis name="server" implement="MAY"/>
<response name="start-ok"/>
<field name="dtx identifier" type="shortstr">
transaction identifier
<doc>
The distributed transaction key. This identifies the transaction
so that the AMQP server can coordinate with the distributed
transaction coordinator.
</doc>
<assert check="notnull"/>
</field>
</method>
<method name="start-ok" synchronous="1" index="21">
confirm the start of a new distributed transaction
<doc>
This method confirms to the client that the transaction started.
Note that if a start fails, the server raises a channel exception.
</doc>
<chassis name="client" implement="MUST"/>
</method>
</class>
<class name="tunnel" handler="tunnel" index="110">
<!--
share/fixed_amqp0-8.xml view on Meta::CPAN
/ C:STRING S:STRING-OK
/ S:STRING C:STRING-OK
/ C:TABLE S:TABLE-OK
/ S:TABLE C:TABLE-OK
/ C:CONTENT S:CONTENT-OK
/ S:CONTENT C:CONTENT-OK
</doc>
<chassis name="server" implement="MUST"/>
<chassis name="client" implement="SHOULD"/>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="integer" synchronous="1" index="10">
test integer handling
<doc>
This method tests the peer's capability to correctly marshal integer
data.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<response name="integer-ok"/>
<field name="integer 1" type="octet">
octet test value
share/fixed_amqp0-8.xml view on Meta::CPAN
The client must execute this operation on the provided integer
test fields and return the result.
</doc>
<assert check="enum">
<value name="add">return sum of test values</value>
<value name="min">return lowest of test values</value>
<value name="max">return highest of test values</value>
</assert>
</field>
</method>
<method name="integer-ok" synchronous="1" index="11">
report integer test result
<doc>
This method reports the result of an Integer method.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<field name="result" type="longlong">
result value
<doc>
The result of the tested operation.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="string" synchronous="1" index="20">
test string handling
<doc>
This method tests the peer's capability to correctly marshal string
data.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<response name="string-ok"/>
<field name="string 1" type="shortstr">
short string test value
share/fixed_amqp0-8.xml view on Meta::CPAN
The client must execute this operation on the provided string
test fields and return the result.
</doc>
<assert check="enum">
<value name="add">return concatentation of test strings</value>
<value name="min">return shortest of test strings</value>
<value name="max">return longest of test strings</value>
</assert>
</field>
</method>
<method name="string-ok" synchronous="1" index="21">
report string test result
<doc>
This method reports the result of a String method.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<field name="result" type="longstr">
result value
<doc>
The result of the tested operation.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="table" synchronous="1" index="30">
test field table handling
<doc>
This method tests the peer's capability to correctly marshal field
table data.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<response name="table-ok"/>
<field name="table" type="table">
field table of test values
share/fixed_amqp0-8.xml view on Meta::CPAN
The client must execute this operation on the provided field
table string values and return the result.
</doc>
<assert check="enum">
<value name="add">return concatenation of string field values</value>
<value name="min">return shortest of string field values</value>
<value name="max">return longest of string field values</value>
</assert>
</field>
</method>
<method name="table-ok" synchronous="1" index="31">
report table test result
<doc>
This method reports the result of a Table method.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<field name="integer result" type="longlong">
integer result value
<doc>
The result of the tested integer operation.
</doc>
</field>
<field name="string result" type="longstr">
string result value
<doc>
The result of the tested string operation.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="content" synchronous="1" content="1" index="40">
test content handling
<doc>
This method tests the peer's capability to correctly marshal content.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<response name="content-ok"/>
</method>
<method name="content-ok" synchronous="1" content="1" index="41">
report content test result
<doc>
This method reports the result of a Content method. It contains the
content checksum and echoes the original content as provided.
</doc>
<chassis name="client" implement="MUST"/>
<chassis name="server" implement="MUST"/>
<field name="content checksum" type="long">
content hash
<doc>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
use-connection = *channel
close-connection = C:CLOSE S:CLOSE-OK
/ S:CLOSE C:CLOSE-OK
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "start" synchronous = "1" index = "10" label = "start connection negotiation">
<doc>
This method starts the connection negotiation process by telling the client the
protocol version that the server proposes, along with a list of security mechanisms
which the client can use for authentication.
</doc>
<rule name = "protocol-name">
<doc>
If the server cannot support the protocol specified in the protocol header,
it MUST respond with a valid protocol header and then close the socket
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</doc>
<doc type = "scenario">
Client connects to server and inspects the locales field. It checks for
the presence of the required locale(s).
</doc>
</rule>
<assert check = "notnull" />
</field>
</method>
<method name = "start-ok" synchronous = "1" index = "11"
label = "select security mechanism and locale">
<doc>
This method selects a SASL security mechanism.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "client-properties" domain = "peer-properties" label = "client properties">
<rule name = "required-fields">
<!-- This rule is not testable from the client side -->
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<doc>
A single message locale selected by the client, which must be one of those
specified by the server.
</doc>
<assert check = "notnull" />
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "secure" synchronous = "1" index = "20" label = "security mechanism challenge">
<doc>
The SASL protocol works by exchanging challenges and responses until both peers have
received sufficient information to authenticate each other. This method challenges
the client to provide more information.
</doc>
<chassis name = "client" implement = "MUST" />
<response name = "secure-ok" />
<field name = "challenge" domain = "longstr" label = "security challenge data">
<doc>
Challenge information, a block of opaque binary data passed to the security
mechanism.
</doc>
</field>
</method>
<method name = "secure-ok" synchronous = "1" index = "21" label = "security mechanism response">
<doc>
This method attempts to authenticate, passing a block of SASL data for the security
mechanism at the server side.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "response" domain = "longstr" label = "security response data">
<doc>
A block of opaque data passed to the security mechanism. The contents of this
data are defined by the SASL security mechanism.
</doc>
<assert check = "notnull" />
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "tune" synchronous = "1" index = "30"
label = "propose connection tuning parameters">
<doc>
This method proposes a set of connection configuration values to the client. The
client can accept and/or adjust these.
</doc>
<chassis name = "client" implement = "MUST" />
<response name = "tune-ok" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</field>
<field name = "heartbeat" domain = "short" label = "desired heartbeat delay">
<doc>
The delay, in seconds, of the connection heartbeat that the server wants.
Zero means the server does not want a heartbeat.
</doc>
</field>
</method>
<method name = "tune-ok" synchronous = "1" index = "31"
label = "negotiate connection tuning parameters">
<doc>
This method sends the client's connection tuning parameters to the server.
Certain fields are negotiated, others provide capability information.
</doc>
<chassis name = "server" implement = "MUST" />
<field name = "channel-max" domain = "short" label = "negotiated maximum channels">
<doc>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
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
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</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
safe to release resources for the connection and close the socket.
</doc>
<rule name = "reporting">
<doc>
A peer that detects a socket closure without having received a Close-Ok
handshake method SHOULD log the error.
</doc>
</rule>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
/ functional-class
close-channel = C:CLOSE S:CLOSE-OK
/ S:CLOSE C:CLOSE-OK
</doc>
<chassis name = "server" implement = "MUST" />
<chassis name = "client" implement = "MUST" />
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "open" synchronous = "1" index = "10" label = "open a channel for use">
<doc>
This method opens a channel to the server.
</doc>
<rule name = "state" on-failure = "channel-error">
<doc>
The client MUST NOT use this method on an already-opened channel.
</doc>
<doc type = "scenario">
Client opens a channel and then reopens the same channel.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<response name = "open-ok" />
<!-- Deprecated: "out-of-band", must be zero -->
<field name = "reserved-1" type = "shortstr" reserved = "1" />
</method>
<method name = "open-ok" synchronous = "1" index = "11" label = "signal that the channel is ready">
<doc>
This method signals to the client that the channel is ready for use.
</doc>
<chassis name = "client" implement = "MUST" />
<!-- Deprecated: "channel-id", must be zero -->
<field name = "reserved-1" type = "longstr" reserved = "1" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "flow" synchronous = "1" index = "20" label = "enable/disable flow from peer">
<doc>
This method asks the peer to pause or restart the flow of content data sent by
a consumer. This is a simple flow-control mechanism that a peer can use to avoid
overflowing its queues or otherwise finding itself receiving more messages than
it can process. Note that this method is not intended for window control. It does
not affect contents returned by Basic.Get-Ok methods.
</doc>
<rule name = "initial-state">
<doc>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<field name = "active" domain = "bit" label = "current flow setting">
<doc>
Confirms the setting of the processed flow method: 1 means the peer will start
sending or continue to send content frames; 0 means it will not.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "close" synchronous = "1" index = "40" label = "request a channel close">
<doc>
This method indicates that the sender wants to close the channel. 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
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</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 = "41" label = "confirm a channel close">
<doc>
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>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</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">
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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"/>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</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">
share/fixed_amqp0-9-1.xml view on Meta::CPAN
/ 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
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</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>
<chassis name = "client" implement = "MUST" />
<field name = "message-count" domain = "message-count">
<doc>
Reports the number of messages purged.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "delete" synchronous = "1" index = "40" label = "delete a queue">
<doc>
This method deletes a queue. When a queue is deleted any pending messages are sent
to a dead-letter queue if this is defined in the server configuration, and all
consumers on the queue are cancelled.
</doc>
<rule name = "01">
<doc>
The server SHOULD use a dead-letter queue to hold messages that were pending on
a deleted queue, and MAY provide facilities for a system administrator to move
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<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>
This method requests a specific quality of service. The QoS can be specified for the
current channel or for all channels on the connection. The particular properties and
semantics of a qos method always depend on the content class semantics. Though the
qos method could in principle apply to both peers, it is currently meaningful only
for the server.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "qos-ok" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</field>
<field name = "global" domain = "bit" label = "apply to entire connection">
<doc>
By default the QoS settings apply to the current channel only. If this field is
set, they are applied to the entire connection.
</doc>
</field>
</method>
<method name = "qos-ok" synchronous = "1" index = "11" label = "confirm the requested qos">
<doc>
This method tells the client that the requested QoS levels could be handled by the
server. The requested QoS applies to all active consumers until a new QoS is
defined.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "consume" synchronous = "1" index = "20" label = "start a queue consumer">
<doc>
This method asks the server to start a "consumer", which is a transient request for
messages from a specific queue. Consumers last as long as the channel they were
declared on, or until the client cancels them.
</doc>
<rule name = "01">
<doc>
The server SHOULD support at least 16 consumers per queue, and ideally, impose
no limit except as defined by available resources.
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<field name = "no-wait" domain = "no-wait" />
<field name = "arguments" domain = "table" label = "arguments for declaration">
<doc>
A set of arguments for the consume. The syntax and semantics of these
arguments depends on the server implementation.
</doc>
</field>
</method>
<method name = "consume-ok" synchronous = "1" index = "21" label = "confirm a new consumer">
<doc>
The server provides the client with a consumer tag, which is used by the client
for methods called on the consumer at a later stage.
</doc>
<chassis name = "client" implement = "MUST" />
<field name = "consumer-tag" domain = "consumer-tag">
<doc>
Holds the consumer tag specified by the client or provided by the server.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "cancel" synchronous = "1" index = "30" label = "end a queue consumer">
<doc>
This method cancels a consumer. This does not affect already delivered
messages, but it does mean the server will not send any more messages for
that consumer. The client may receive an arbitrary number of messages in
between sending the cancel method and receiving the cancel-ok reply.
It may also be sent from the server to the client in the event
of the consumer being unexpectedly cancelled (i.e. cancelled
for any reason other than the server receiving the
corresponding basic.cancel from the client). This allows
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</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>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
share/fixed_amqp0-9-1.xml view on Meta::CPAN
Specifies the routing key name specified when the message was published.
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "deliver" content = "1" index = "60"
label = "notify the client of a consumer message">
<doc>
This method delivers a message to the client, via a consumer. In the asynchronous
message delivery model, the client starts a consumer using the Consume method, then
the server responds with Deliver methods as and when messages arrive for that
consumer.
</doc>
<rule name = "01">
<doc>
The server SHOULD track the number of times a message has been delivered to
clients and when a message is redelivered a certain number of times - e.g. 5
times - without being acknowledged, the server SHOULD consider the message to be
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</doc>
</field>
<field name = "routing-key" domain = "shortstr" label = "Message routing key">
<doc>Specifies the routing key name specified when the message was published.</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "get" synchronous = "1" index = "70" label = "direct access to a queue">
<doc>
This method provides a direct access to the messages in a queue using a synchronous
dialogue that is designed for specific types of application where synchronous
functionality is more important than performance.
</doc>
<response name = "get-ok" />
<response name = "get-empty" />
<chassis name = "server" implement = "MUST" />
<!-- 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 get a message from.</doc>
</field>
<field name = "no-ack" domain = "no-ack" />
</method>
<method name = "get-ok" synchronous = "1" content = "1" index = "71"
label = "provide client with a message">
<doc>
This method delivers a message to the client following a get method. A message
delivered by 'get-ok' must be acknowledged unless the no-ack option was set in the
get method.
</doc>
<chassis name = "client" implement = "MAY" />
<field name = "delivery-tag" domain = "delivery-tag" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</doc>
</field>
<field name = "routing-key" domain = "shortstr" label = "Message routing key">
<doc>Specifies the routing key name specified when the message was published.</doc>
</field>
<field name = "message-count" domain = "message-count" />
</method>
<method name = "get-empty" synchronous = "1" index = "72"
label = "indicate no messages available">
<doc>
This method tells the client that the queue has no messages available for the
client.
</doc>
<chassis name = "client" implement = "MAY" />
<!-- Deprecated: "cluster-id", must be empty -->
<field name = "reserved-1" type = "shortstr" reserved = "1" />
</method>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "recover-async" index = "100" label = "redeliver unacknowledged messages"
deprecated = "1">
<doc>
This method asks the server to redeliver all unacknowledged messages on a
specified channel. Zero or more messages may be redelivered. This method
is deprecated in favour of the synchronous Recover/Recover-Ok.
</doc>
<rule name = "01">
<doc>
The server MUST set the redelivered flag on all messages that are resent.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<chassis name = "server" implement = "MAY" />
share/fixed_amqp0-9-1.xml view on Meta::CPAN
</doc>
</field>
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "recover" index = "110" label = "redeliver unacknowledged messages">
<doc>
This method asks the server to redeliver all unacknowledged messages on a
specified channel. Zero or more messages may be redelivered. This method
replaces the asynchronous Recover.
</doc>
<rule name = "01">
<doc>
The server MUST set the redelivered flag on all messages that are resent.
</doc>
<doc type = "scenario">
TODO.
</doc>
</rule>
<chassis name = "server" implement = "MUST" />
<field name = "requeue" domain = "bit" label = "requeue the message">
<doc>
If this field is zero, the message will be redelivered to the original
recipient. If this bit is 1, the server will attempt to requeue the message,
potentially then delivering it to an alternative subscriber.
</doc>
</field>
</method>
<method name = "recover-ok" synchronous = "1" index = "111" label = "confirm recovery">
<doc>
This method acknowledges a Basic.Recover method.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<method name = "nack" index = "120" label = "reject one or more incoming messages">
<doc>
This method allows a client to reject one or more incoming messages. It can be
used to interrupt and cancel large incoming messages, or return untreatable
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<!-- == TX =============================================================== -->
<class name = "tx" handler = "channel" index = "90" label = "work with transactions">
<doc>
The Tx class allows publish and ack operations to be batched into atomic
units of work. The intention is that all publish and ack requests issued
within a transaction will complete successfully or none of them will.
Servers SHOULD implement atomic transactions at least where all publish
or ack requests affect a single queue. Transactions that cover multiple
queues may be non-atomic, given that queues can be created and destroyed
asynchronously, and such events do not form part of any transaction.
Further, the behaviour of transactions with respect to the immediate and
mandatory flags on Basic.Publish methods is not defined.
</doc>
<rule name = "not multiple queues">
<doc>
Applications MUST NOT rely on the atomicity of transactions that
affect more than one queue.
</doc>
</rule>
share/fixed_amqp0-9-1.xml view on Meta::CPAN
tx = C:SELECT S:SELECT-OK
/ C:COMMIT S:COMMIT-OK
/ C:ROLLBACK S:ROLLBACK-OK
</doc>
<chassis name = "server" implement = "SHOULD" />
<chassis name = "client" implement = "MAY" />
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "select" synchronous = "1" index = "10" label = "select standard transaction mode">
<doc>
This method sets the channel to use standard transactions. The client must use this
method at least once on a channel before using the Commit or Rollback methods.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "select-ok" />
</method>
<method name = "select-ok" synchronous = "1" index = "11" label = "confirm transaction mode">
<doc>
This method confirms to the client that the channel was successfully set to use
standard transactions.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "commit" synchronous = "1" index = "20" label = "commit the current transaction">
<doc>
This method commits all message publications and acknowledgments performed in
the current transaction. A new transaction starts immediately after a commit.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "commit-ok" />
<rule name = "transacted" on-failure = "precondition-failed">
<doc>
The client MUST NOT use the Commit method on non-transacted channels.
</doc>
<doc type = "scenario">
The client opens a channel and then uses Tx.Commit.
</doc>
</rule>
</method>
<method name = "commit-ok" synchronous = "1" index = "21" label = "confirm a successful commit">
<doc>
This method confirms to the client that the commit succeeded. Note that if a commit
fails, the server raises a channel exception.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name = "rollback" synchronous = "1" index = "30"
label = "abandon the current transaction">
<doc>
This method abandons all message publications and acknowledgments performed in
the current transaction. A new transaction starts immediately after a rollback.
Note that unacked messages will not be automatically redelivered by rollback;
if that is required an explicit recover call should be issued.
</doc>
<chassis name = "server" implement = "MUST" />
<response name = "rollback-ok" />
<rule name = "transacted" on-failure = "precondition-failed">
<doc>
The client MUST NOT use the Rollback method on non-transacted channels.
</doc>
<doc type = "scenario">
The client opens a channel and then uses Tx.Rollback.
</doc>
</rule>
</method>
<method name = "rollback-ok" synchronous = "1" index = "31" label = "confirm successful rollback">
<doc>
This method confirms to the client that the rollback succeeded. Note that if an
rollback fails, the server raises a channel exception.
</doc>
<chassis name = "client" implement = "MUST" />
</method>
</class>
<!-- == CONFIRM ========================================================== -->
share/fixed_amqp0-9-1.xml view on Meta::CPAN
<doc type = "grammar">
confirm = C:SELECT S:SELECT-OK
</doc>
<chassis name = "server" implement = "SHOULD" />
<chassis name = "client" implement = "MAY" />
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
<method name="select" synchronous="1" index="10">
select confirm mode (i.e. enable publisher acknowledgements)
<doc>
This method sets the channel to use publisher acknowledgements.
The client can only use this method on a non-transactional
channel.
</doc>
<chassis name="server" implement="MUST"/>
<response name="select-ok"/>
<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="select-ok" synchronous="1" index="11">
acknowledge confirm mode
<doc>
This method confirms to the client that the channel was successfully
set to use publisher acknowledgements.
</doc>
<chassis name="client" implement="MUST"/>
</method>
</class>
</amqp>
( run in 0.335 second using v1.01-cache-2.11-cpan-0d8aa00de5b )