AMQP 0-9-1 Complete Reference Guide

This page contains a complete reference to RabbitMQ's implementaton of version 0-9-1 of the AMQP specification. The
original specification was published by
the AMQP WG in 2008 and is made available under the
AMQP license.

Methods

start(

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.

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
connection.

The server MUST provide a protocol version that is lower than or equal to
that requested by the client in the protocol header.

If the client cannot handle the protocol version suggested by the server
it MUST close the socket connection without sending any further data.

The properties SHOULD contain at least these fields: "host", specifying the
server host name or address, "product", giving the name of the server product,
"version", giving the name of the server version, "platform", giving the name
of the operating system, "copyright", if appropriate, and "information", giving
other general information.

Parameters:

The properties SHOULD contain at least these fields: "product", giving the name
of the client product, "version", giving the name of the client version, "platform",
giving the name of the operating system, "copyright", if appropriate, and
"information", giving other general information.

secure(

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.

Parameters:

The largest frame size that the server proposes for the connection, including
frame header and end-byte. The client can negotiate a lower value. Zero means
that the server does not impose any specific limit but may reject very large
frames if it cannot allocate resources for them.

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.

Parameters:

The maximum total number of channels that the client will use per connection.

If the client specifies a channel 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.

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.

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.

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.

open(

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.

Parameters:

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.

The server SHOULD verify that the client has permission to access the
specified virtual host.

Parameters:

close(

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.

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.

Parameters:

flow(

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.

When a new channel is opened, it is active (flow is active). Some applications
assume that channels are inactive until started. To emulate this behaviour a
client MAY open the channel, then pause it.

When sending content frames, a peer SHOULD monitor the channel for incoming
methods and respond to a Channel.Flow as rapidly as possible.

A peer MAY use the Channel.Flow method to throttle incoming content data for
internal reasons, for example, when exchanging data over a slower connection.

The peer that requests a Channel.Flow method MAY disconnect and/or ban a peer
that does not respect the request. This is to prevent badly-behaved clients
from overwhelming a server.

close(

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.

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.

The server MUST implement these standard exchange types: fanout, direct.

The server SHOULD implement these standard exchange types: topic, headers.

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.
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.

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.

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.

Parameters:

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.
Error code: access-refused

The exchange name consists of a non-empty sequence of these characters:
letters, digits, hyphen, underscore, period, or colon.
Error code: precondition-failed

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.

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.
Error code: not-allowed

The client MUST NOT attempt to declare an exchange with a type that the
server does not support.
Error code: command-invalid

If set, the server will reply with Declare-Ok if the exchange already
exists with the same name, and raise an error if not. The client can
use this to check whether an exchange exists without modifying the
server state. When set, all other method fields except name and no-wait
are ignored. A declare with both passive and no-wait has no effect.
Arguments are compared for semantic equivalence.

If set, and the exchange does not already exist, the server MUST
raise a channel exception with reply code 404 (not found).

If not set and the exchange exists, the server MUST check that the
existing exchange has the same values for type, durable, and arguments
fields. The server MUST respond with Declare-Ok if the requested
exchange matches these fields, and MUST raise a channel exception if
not.

If set when creating a new exchange, the exchange will be marked as durable.
Durable exchanges remain active when a server restarts. Non-durable exchanges
(transient exchanges) are purged if/when a server restarts.

If set, the exchange is deleted when all queues have
finished using it.

The server SHOULD allow for a reasonable delay between the
point when it determines that an exchange is not being
used (or no longer used), and the point when it deletes
the exchange. At the least it must allow a client to
create an exchange and then bind a queue to it, with a
small but non-zero delay between these two actions.

The server MUST ignore the auto-delete field if the
exchange already exists.

Specifies the routing key for the binding. The routing key
is used for routing messages depending on the exchange
configuration. Not all exchanges use a routing key - refer
to the specific exchange documentation.

Methods

declare(

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.

The server MUST create a default binding for a newly-declared queue to the
default exchange, which is an exchange of type 'direct' and use the queue
name as the routing key.

The server SHOULD support a minimum of 256 queues per virtual host and ideally,
impose no limit except as defined by available resources.

Parameters:

The queue name MAY be empty, in which case the server MUST create a new
queue with a unique generated name and return this to the client in the
Declare-Ok method.

Queue names starting with "amq." are reserved for pre-declared and
standardised queues. The client MAY declare a queue starting with
"amq." if the passive option is set, or the queue already exists.
Error code: access-refused

The queue name can be empty, or a sequence of these characters:
letters, digits, hyphen, underscore, period, or colon.
Error code: precondition-failed

If set, the server will reply with Declare-Ok if the queue already
exists with the same name, and raise an error if not. The client can
use this to check whether a queue exists without modifying the
server state. When set, all other method fields except name and no-wait
are ignored. A declare with both passive and no-wait has no effect.
Arguments are compared for semantic equivalence.

The client MAY ask the server to assert that a queue exists without
creating the queue if not. If the queue does not exist, the server
treats this as a failure.
Error code: not-found

If not set and the queue exists, the server MUST check that the
existing queue has the same values for durable, exclusive, auto-delete,
and arguments fields. The server MUST respond with Declare-Ok if the
requested queue matches these fields, and MUST raise a channel exception
if not.

If set when creating a new queue, the queue will be marked as durable. Durable
queues remain active when a server restarts. Non-durable queues (transient
queues) are purged if/when a server restarts. Note that durable queues do not
necessarily hold persistent messages, although it does not make sense to send
persistent messages to a transient queue.

If set, the queue is deleted when all consumers have finished using it. The last
consumer can be cancelled either explicitly or because its channel is closed. If
there was no consumer ever on the queue, it won't be deleted. Applications can
explicitly delete auto-delete queues using the Delete method as normal.

The server MUST ignore the auto-delete field if the queue already exists.

bind(

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.

A server MUST allow ignore duplicate bindings - that is, two or more bind
methods for a specific queue, with identical arguments - without treating these
as an error.

A server MUST not deliver the same message more than once to a queue, even if
the queue has multiple bindings that match the message.

The server MUST allow a durable queue to bind to a transient exchange.

Bindings of durable queues to durable exchanges are automatically durable
and the server MUST restore such bindings after a server restart.

The server SHOULD support at least 4 bindings per queue, and ideally, impose no
limit except as defined by available resources.

Specifies the routing key for the binding. The routing key is used for routing
messages depending on the exchange configuration. Not all exchanges use a
routing key - refer to the specific exchange documentation. If the queue name
is empty, the server uses the last queue declared on the channel. If the
routing key is also empty, the server uses this queue name for the routing
key as well. If the queue name is provided but the routing key is empty, the
server does the binding with that empty routing key. The meaning of empty
routing keys depends on the exchange implementation.

If a message queue binds to a direct exchange using routing key K and a
publisher sends the exchange a message with routing key R, then the message
MUST be passed to the message queue if K = R.

unbind-ok(

)

purge(

This method removes all messages from a queue which are not awaiting
acknowledgment.

The server MUST NOT purge messages that have already been sent to a client
but not yet acknowledged.

The server MAY implement a purge queue or log that allows system administrators
to recover accidentally-purged messages. The server SHOULD NOT keep purged
messages in the same storage spaces as the live messages since the volumes of
purged messages may get very large.

Methods

qos(

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.

Parameters:

The client can request that messages be sent in advance so that when the client
finishes processing a message, the following message is already held locally,
rather than needing to be sent down the channel. Prefetching gives a performance
improvement. This field specifies the prefetch window size in octets. The server
will send a message in advance if it is equal to or smaller in size than the
available prefetch size (and also falls into other prefetch limits). May be set
to zero, meaning "no specific limit", although other prefetch limits may still
apply. The prefetch-size is ignored if the no-ack option is set.

The server MUST ignore this setting when the client is not processing any
messages - i.e. the prefetch size does not limit the transfer of single
messages to a client, only the sending in advance of more messages while
the client still has one or more unacknowledged messages.

Specifies a prefetch window in terms of whole messages. This field may be used
in combination with the prefetch-size field; a message will only be sent in
advance if both prefetch windows (and those at the channel and connection level)
allow it. The prefetch-count is ignored if the no-ack option is set.

The server may send less data in advance than allowed by the client's
specified prefetch windows but it MUST NOT send more.

RabbitMQ has reinterpreted this field. The original
specification said: "By default the QoS settings apply to
the current channel only. If this field is set, they are
applied to the entire connection." Instead, RabbitMQ takes
global=false to mean that the QoS settings should apply
per-consumer (for new consumers on the channel; existing
ones being unaffected) and global=true to mean that the QoS
settings should apply per-channel.

consume(

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.

The server SHOULD support at least 16 consumers per queue, and ideally, impose
no limit except as defined by available resources.

Parameters:

cancel(

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
clients to be notified of the loss of consumers due to events
such as queue deletion. Note that as it is not a MUST for
clients to accept this method from the server, it is advisable
for the broker to be able to identify those clients that are
capable of accepting the method, through some means of
capability negotiation.

If the queue does not exist the server MUST ignore the cancel method, so
long as the consumer tag is valid for that channel.

Parameters:

publish(

This method publishes a message to a specific exchange. The message will be routed
to queues as defined by the exchange configuration and distributed to any active
consumers when the transaction, if any, is committed.

Parameters:

Specifies the name of the exchange to publish to. The exchange name can be
empty, meaning the default exchange. If the exchange name is specified, and that
exchange does not exist, the server will raise a channel exception.

The client MUST NOT attempt to publish a content to an exchange that
does not exist.
Error code: not-found

The server MUST accept a blank exchange name to mean the default exchange.

If the exchange was declared as an internal exchange, the server MUST raise
a channel exception with a reply code 403 (access refused).

The exchange MAY refuse basic content in which case it MUST raise a channel
exception with reply code 540 (not implemented).

This flag tells the server how to react if the message cannot be routed to a
queue. If this flag is set, the server will return an unroutable message with a
Return method. If this flag is zero, the server silently drops the message.

This flag tells the server how to react if the message cannot be routed to a
queue consumer immediately. If this flag is set, the server will return an
undeliverable message with a Return method. If this flag is zero, the server
will queue the message, but with no guarantee that it will ever be consumed.

return(

This method returns an undeliverable message that was published with the "immediate"
flag set, or an unroutable message published with the "mandatory" flag set. The
reply code and text provide information about the reason that the message was
undeliverable.

deliver(

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.

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.

get(

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.

Parameters:

ack(

When sent by the client, this method acknowledges one or more
messages delivered via the Deliver or Get-Ok methods.
When sent by server, this method acknowledges one or more
messages published with the Publish method on a channel in
confirm mode.
The acknowledgement can be for a single message or a set of
messages up to and including a specific message.

Parameters:

If set to 1, the delivery tag is treated as "up to and
including", so that multiple messages can be acknowledged
with a single method. If set to zero, the delivery tag
refers to a single message. If the multiple field is 1, and
the delivery tag is zero, this indicates acknowledgement of
all outstanding messages.

A message MUST not be acknowledged more than once. The
receiving peer MUST validate that a non-zero delivery-tag
refers to a delivered message, and raise a channel
exception if this is not the case. On a transacted
channel, this check MUST be done immediately and not
delayed until a Tx.Commit.
Error code: precondition-failed

reject(

This method allows a client to reject a message. It can be used to interrupt and
cancel large incoming messages, or return untreatable messages to their original
queue.

The server SHOULD be capable of accepting and process the Reject method while
sending message content with a Deliver or Get-Ok method. I.e. the server should
read and process incoming methods while sending output frames. To cancel a
partially-send content, the server sends a content body frame of size 1 (i.e.
with no data except the frame-end octet).

The server SHOULD interpret this method as meaning that the client is unable to
process the message at this time.

The client MUST NOT use this method as a means of selecting messages to process.

Parameters:

If requeue is true, the server will attempt to requeue the message. If requeue
is false or the requeue attempt fails the messages are discarded or dead-lettered.

The server MUST NOT deliver the message to the same client within the
context of the current channel. The recommended strategy is to attempt to
deliver the message to an alternative consumer, and if that is not possible,
to move the message to a dead-letter queue. The server MAY use more
sophisticated tracking to hold the message on the queue and redeliver it to
the same client at a later stage.

recover-async(

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.

The server MUST set the redelivered flag on all messages that are resent.

Parameters:

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.

Parameters:

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.

recover-ok(

)

nack(

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
messages to their original queue.
This method is also used by the server to inform publishers on channels in
confirm mode of unhandled messages. If a publisher receives this method, it
probably needs to republish the offending messages.

The server SHOULD be capable of accepting and processing the Nack method while
sending message content with a Deliver or Get-Ok method. I.e. the server should
read and process incoming methods while sending output frames. To cancel a
partially-send content, the server sends a content body frame of size 1 (i.e.
with no data except the frame-end octet).

The server SHOULD interpret this method as meaning that the client is unable to
process the message at this time.

The client MUST NOT use this method as a means of selecting messages to process.

A client publishing messages to a channel in confirm mode SHOULD be capable of accepting
and somehow handling the Nack method.

Parameters:

If set to 1, the delivery tag is treated as "up to and
including", so that multiple messages can be rejected
with a single method. If set to zero, the delivery tag
refers to a single message. If the multiple field is 1, and
the delivery tag is zero, this indicates rejection of
all outstanding messages.

A message MUST not be rejected more than once. The
receiving peer MUST validate that a non-zero delivery-tag
refers to an unacknowledged, delivered message, and
raise a channel exception if this is not the case.
Error code: precondition-failed

If requeue is true, the server will attempt to requeue the message. If requeue
is false or the requeue attempt fails the messages are discarded or dead-lettered.
Clients receiving the Nack methods should ignore this flag.

The server MUST NOT deliver the message to the same client within the
context of the current channel. The recommended strategy is to attempt to
deliver the message to an alternative consumer, and if that is not possible,
to move the message to a dead-letter queue. The server MAY use more
sophisticated tracking to hold the message on the queue and redeliver it to
the same client at a later stage.

tx

Work with transactions.

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.

rollback(

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.

The client MUST NOT use the Rollback method on non-transacted channels.
Error code: precondition-failed

rollback-ok(

)

confirm

Work with confirms.

The Confirm class allows publishers to put the channel in
confirm mode and subsequently be notified when messages have been
handled by the broker. The intention is that all messages
published on a channel in confirm mode will be acknowledged at
some point. By acknowledging a message the broker assumes
responsibility for it and indicates that it has done something
it deems reasonable with it.
Unroutable mandatory or immediate messages are acknowledged
right after the Basic.Return method. Messages are acknowledged
when all queues to which the message has been routed
have either delivered the message and received an
acknowledgement (if required), or enqueued the message (and
persisted it if required).
Published messages are assigned ascending sequence numbers,
starting at 1 with the first Confirm.Select method. The server
confirms messages by sending Basic.Ack methods referring to these
sequence numbers.

Class Grammar:

confirm = C:SELECT S:SELECT-OK

The server MUST acknowledge all messages received after the
channel was put into confirm mode.

The server MUST acknowledge a message only after it was
properly handled by all the queues it was delivered to.

The server MUST acknowledge an unroutable mandatory or
immediate message only after it sends the Basic.Return.

No guarantees are made as to how soon a message is
acknowledged. Applications SHOULD NOT make assumptions about
this.

The delivery tag is valid only within the channel from which the message was
received. I.e. a client MUST NOT receive a message on one channel and then
acknowledge it on another.

The server MUST NOT use a zero value for delivery tags. Zero is reserved
for client use, meaning "all messages so far received".

exchange-name

shortstr

The exchange name is a client-selected string that identifies the exchange for
publish methods.

long

long

[32-bit integer]

longlong

longlong

[64-bit integer]

longstr

longstr

[long string]

message-count

long

The number of messages in the queue, which will be zero for newly-declared
queues. This is the number of messages present in the queue, and committed
if the channel on which they were published is transacted, that are not
waiting acknowledgement.

method-id

short

no-ack

bit

If this field is set the server does not expect acknowledgements for
messages. That is, when a message is delivered to the client the server
assumes the delivery will succeed and immediately dequeues it. This
functionality may increase performance but at the cost of reliability.
Messages can get lost if a client dies before they are delivered to the
application.

no-local

bit

If the no-local field is set the server will not send messages to the connection that
published them.

no-wait

bit

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.

octet

octet

[single octet]

path

shortstr

Unconstrained.

peer-properties

table

This table provides a set of peer properties, used for identification, debugging,
and general information.

queue-name

shortstr

The queue name identifies the queue within the vhost. In methods where the queue
name may be blank, and that has no specific significance, this refers to the
'current' queue for the channel, meaning the last queue that the client declared
on the channel. If the client did not declare a queue, and the method needs a
queue name, this will result in a 502 (syntax error) channel exception.

redelivered

bit

This indicates that the message has been previously delivered to this or
another client.

The server SHOULD try to signal redelivered messages when it can. When
redelivering a message that was not successfully acknowledged, the server
SHOULD deliver it to the original client if possible.

The client MUST NOT rely on the redelivered field but should take it as a
hint that the message may already have been processed. A fully robust
client must be able to track duplicate received messages on non-transacted,
and locally-transacted channels.

reply-code

short

The reply code. The AMQ reply codes are defined as constants at the start
of this formal specification.

reply-text

shortstr

The localised reply text. This text can be logged as an aid to resolving
issues.

Constants

Many constants are error codes. Where this is so, they fall into one of two categories:

Channel Errors: These are associated with failures that affect the current channel
but no other channels created from the same connection.

Connection Errors: These are associated with failures that preclude any further
activity on the connection and mandate its closure.

The following constants are defined in the specification:

Name

Value

Error Class

Description

frame-method

1

frame-header

2

frame-body

3

frame-heartbeat

8

frame-min-size

4096

frame-end

206

reply-success

200

Indicates that the method completed successfully. This reply code is
reserved for future use - the current protocol design does not use positive
confirmation and reply codes are sent only in case of an error.

content-too-large

311

channel

The client attempted to transfer content larger than the server could accept
at the present time. The client may retry at a later time.

no-consumers

313

channel

When the exchange cannot deliver to a consumer when the immediate flag is
set. As a result of pending data on the queue or the absence of any
consumers of the queue.

connection-forced

320

connection

An operator intervened to close the connection for some reason. The client
may retry at some later date.

invalid-path

402

connection

The client tried to work with an unknown virtual host.

access-refused

403

channel

The client attempted to work with a server entity to which it has no
access due to security settings.

not-found

404

channel

The client attempted to work with a server entity that does not exist.

resource-locked

405

channel

The client attempted to work with a server entity to which it has no
access because another client is working with it.

precondition-failed

406

channel

The client requested a method that was not allowed because some precondition
failed.

frame-error

501

connection

The sender sent a malformed frame that the recipient could not decode.
This strongly implies a programming error in the sending peer.

syntax-error

502

connection

The sender sent a frame that contained illegal values for one or more
fields. This strongly implies a programming error in the sending peer.

command-invalid

503

connection

The client sent an invalid sequence of frames, attempting to perform an
operation that was considered invalid by the server. This usually implies
a programming error in the client.

channel-error

504

connection

The client attempted to work with a channel that had not been correctly
opened. This most likely indicates a fault in the client layer.

unexpected-frame

505

connection

The peer sent a frame that was not expected, usually in the context of
a content header and body. This strongly indicates a fault in the peer's
content processing.

resource-error

506

connection

The server could not complete the method because it lacked sufficient
resources. This may be due to the client creating too many of some type
of entity.

not-allowed

530

connection

The client tried to work with some entity in a manner that is prohibited
by the server, due to security settings or by some other criteria.

not-implemented

540

connection

The client tried to use functionality that is not implemented in the
server.

internal-error

541

connection

The server could not complete the method because of an internal error.
The server may require intervention by an operator in order to resume
normal operations.

Getting Help and Providing Feedback

If you have questions about the contents of this guide or
any other topic related to RabbitMQ, don't hesitate to ask them
on the RabbitMQ mailing list.

Help Us Improve the Docs <3

If you'd like to contribute an improvement to the site,
its source is available on GitHub.
Simply fork the repository and submit a pull request. Thank you!