OASIS AMQP Version 1.0
Part 3 : Messaging

Committee Specification Draft 02 /
Public Review Draft 02

29 May 2012

Specification URIs

This version:

http://docs.oasis-open.org/amqp/core/v1.0/csprd02/amqp-core-messaging-v1.0-csprd02.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/csprd02/amqp-core-messaging-v1.0-csprd02.html

http://docs.oasis-open.org/amqp/core/v1.0/csprd02/amqp-core-complete-v1.0-csprd02.pdf

Previous version:

http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-messaging-v1.0-csprd01.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-messaging-v1.0-csprd01.html

http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-complete-v1.0-csprd01.pdf

Latest version:

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-messaging-v1.0.xml (Authoritative)

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-messaging-v1.0.html

http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf

Technical Committee:

OASIS AMQP Technical Committee

Chairs:

Ram Jeyaraman (Ram.Jeyaraman@microsoft.com), Microsoft

Angus Telfer (angus.telfer@inetco.com), INETCO Systems

Editors:

Robert Godfrey (robert.godfrey@jpmorgan.com), JPMorgan Chase & Co.

David Ingham (David.Ingham@microsoft.com), Microsoft

Rafael Schloming (rafaels@redhat.com), Red Hat

Additional artifacts:

This specification consists of the following documents:

·        Part 0: Overview - Overview of the AMQP specification

·        Part 1: Types - AMQP type system and encoding

·        Part 2: Transport - AMQP transport layer

·        Part 3: Messaging (this document) - AMQP Messaging Layer

·        Part 4: Transactions - AMQP Transactions Layer

·        Part 5: Security - AMQP Security Layers

·        XML Document Type Definition (DTD)

Related work:

This specification replaces or supersedes:

·        http://www.amqp.org/specification/1.0/amqp-org-download

Abstract:

The Advanced Message Queuing Protocol (AMQP) is an open internet protocol for business messaging. It defines a binary wire-level protocol that allows for the reliable exchange of business messages between two parties. AMQP has a layered architecture and the specification is organized as a set of parts that reflects that architecture. Part 1 defines the AMQP type system and encoding. Part 2 defines the AMQP transport layer, an efficient, binary, peer-to-peer protocol for transporting messages between two processes over a network. Part 3 defines the AMQP message format, with a concrete encoding. Part 4 defines how interactions can be grouped within atomic transactions. Part 5 defines the AMQP security layers.

Status:

This document was last revised or approved by the OASIS AMQP Technical Committee on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the "Send A Comment" button on the Technical Committee's web page at http://www.oasis-open.org/committees/amqp/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/amqp/ipr.php).

Citation format:

When referencing this specification the following citation format should be used:

[amqp-core-messaging-v1.0]

OASIS AMQP Version 1.0 Part 3 : Messaging. 29 May 2012. Committee Specification Draft 02 / Public Review Draft 02. http://docs.oasis-open.org/amqp/core/v1.0/csprd02/amqp-core-messaging-v1.0-csprd02.html.


Notices

Copyright OASIS Open 2012. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.


Table of Contents



3.1 Introduction
3.2 Message Format
      3.2.1 Header
      3.2.2 Delivery Annotations
      3.2.3 Message Annotations
      3.2.4 Properties
      3.2.5 Application Properties
      3.2.6 Data
      3.2.7 Amqp Sequence
      3.2.8 Amqp Value
      3.2.9 Footer
      3.2.10 Annotations
      3.2.11 Message Id Ulong
      3.2.12 Message Id Uuid
      3.2.13 Message Id Binary
      3.2.14 Message Id String
      3.2.15 Address String
      3.2.16 Constant Definitions
3.3 Distribution Nodes
3.4 Delivery State
      3.4.1 Received
      3.4.2 Accepted
      3.4.3 Rejected
      3.4.4 Released
      3.4.5 Modified
      3.4.6 Resuming Deliveries Using Delivery States
3.5 Sources and Targets
      3.5.1 Filtering Messages
      3.5.2 Distribution Modes
      3.5.3 Source
      3.5.4 Target
      3.5.5 Terminus Durability
      3.5.6 Terminus Expiry Policy
      3.5.7 Std Dist Mode
      3.5.8 Filter Set
      3.5.9 Node Properties
      3.5.10 Delete On Close
      3.5.11 Delete On No Links
      3.5.12 Delete On No Messages
      3.5.13 Delete On No Links Or Messages

3.1 Introduction

The messaging layer builds on top of the concepts described in Types and Transport. The transport layer defines a number of extension points suitable for use in a variety of different messaging applications. The messaging layer specifies a standardized use of these to provide interoperable messaging capabilities. This standard covers:

3.2 Message Format

The term message is used with various connotations in the messaging world. The sender might like to think of the message as an immutable payload handed off to the messaging infrastructure for delivery. The receiver often thinks of the message as not only that immutable payload from the sender, but also various annotations supplied by the messaging infrastructure along the way. To avoid confusion we formally define the term bare message to mean the message as supplied by the sender and the term annotated message to mean the message as seen at the receiver.

An annotated message consists of the bare message plus sections for annotation at the head and tail of the bare message. There are two classes of annotations: annotations that travel with the message indefinitely, and annotations that are consumed by the next node.

The bare message consists of three sections: standard properties, application-properties, and application-data (the body).

Bare Message | .---------------------+--------------------. | | +--------+-------------+-------------+------------+--------------+--------------+--------+ | header | delivery- | message- | properties | application- | application- | footer | | | annotations | annotations | | properties | data | | +--------+-------------+-------------+------------+--------------+--------------+--------+ | | '-------------------------------------------+--------------------------------------------' | Annotated Message

The bare message is immutable within the AMQP network. That is, none of the sections can be changed by any node acting as an AMQP intermediary. If a section of the bare message is omitted, one MUST NOT be inserted by an intermediary. The exact encoding of sections of the bare message MUST NOT be modified. This preserves message hashes, HMACs and signatures based on the binary encoding of the bare message.

The exact structure of a message, together with its encoding, is defined by the message format. This document defines the structure and semantics of message format 0 (MESSAGE-FORMAT). Altogether a message consists of the following sections:

3.2.1 Header

Transport headers for a message.

<type name="header" class="composite" source="list" provides="section"> <descriptor name="amqp:header:list" code="0x00000000:0x00000070"/> <field name="durable" type="boolean" default="false"/> <field name="priority" type="ubyte" default="4"/> <field name="ttl" type="milliseconds"/> <field name="first-acquirer" type="boolean" default="false"/> <field name="delivery-count" type="uint" default="0"/> </type>

The header section carries standard delivery details about the transfer of a message through the AMQP network. If the header section is omitted the receiver MUST assume the appropriate default values (or the meaning implied by no value being set) for the fields within the header unless other target or node specific defaults have otherwise been set.

durablespecify durability requirementsoptional boolean

Durable messages MUST NOT be lost even if an intermediary is unexpectedly terminated and restarted. A target which is not capable of fulfilling this guarantee MUST NOT accept messages where the durable header is set to true: if the source allows the rejected outcome then the message SHOULD be rejected with the precondition-failed error, otherwise the link MUST be detached by the receiver with the same error.

priorityrelative message priorityoptional ubyte

This field contains the relative message priority. Higher numbers indicate higher priority messages. Messages with higher priorities MAY be delivered before those with lower priorities.

An AMQP intermediary implementing distinct priority levels MUST do so in the following manner:

  • If n distinct priorities are implemented and n is less than 10 -- priorities 0 to (5 - ceiling(n/2)) MUST be treated equivalently and MUST be the lowest effective priority. The priorities (4 + floor(n/2)) and above MUST be treated equivalently and MUST be the highest effective priority. The priorities (5 - ceiling(n/2)) to (4 + floor(n/2)) inclusive MUST be treated as distinct priorities.

  • If n distinct priorities are implemented and n is 10 or greater -- priorities 0 to (n - 1) MUST be distinct, and priorities n and above MUST be equivalent to priority (n - 1).

Thus, for example, if 2 distinct priorities are implemented, then levels 0 to 4 are equivalent, and levels 5 to 9 are equivalent and levels 4 and 5 are distinct. If 3 distinct priorities are implements the 0 to 3 are equivalent, 5 to 9 are equivalent and 3, 4 and 5 are distinct.

This scheme ensures that if two priorities are distinct for a server which implements m separate priority levels they are also distinct for a server which implements n different priority levels where n > m.

ttltime to live in msoptional milliseconds

Duration in milliseconds for which the message is to be considered "live". If this is set then a message expiration time will be computed based on the time of arrival at an intermediary. Messages that live longer than their expiration time will be discarded (or dead lettered). When a message is transmitted by an intermediary that was received with a ttl, the transmitted message's header SHOULD contain a ttl that is computed as the difference between the current time and the formerly computed message expiration time, i.e., the reduced ttl, so that messages will eventually die if they end up in a delivery loop.

first-acquireroptional boolean

If this value is true, then this message has not been acquired by any other link (see section 3.3). If this value is false, then this message MAY have previously been acquired by another link or links.

delivery-countthe number of prior unsuccessful delivery attemptsoptional uint

The number of unsuccessful previous attempts to deliver this message. If this value is non-zero it can be taken as an indication that the delivery might be a duplicate. On first delivery, the value is zero. It is incremented upon an outcome being settled at the sender, according to rules defined for each outcome.

3.2.2 Delivery Annotations

<type name="delivery-annotations" class="restricted" source="annotations" provides="section"> <descriptor name="amqp:delivery-annotations:map" code="0x00000000:0x00000071"/> </type>

The delivery-annotations section is used for delivery-specific non-standard properties at the head of the message. Delivery annotations convey information from the sending peer to the receiving peer. If the recipient does not understand the annotation it cannot be acted upon and its effects (such as any implied propagation) cannot be acted upon. Annotations might be specific to one implementation, or common to multiple implementations. The capabilities negotiated on link attach and on the source and target SHOULD be used to establish which annotations a peer supports. A registry of defined annotations and their meanings is maintained [AMQPDELANN]. The symbolic key "rejected" is reserved for the use of communicating error information regarding rejected messages. Any values associated with the "rejected" key MUST be of type error.

If the delivery-annotations section is omitted, it is equivalent to a delivery-annotations section containing an empty map of annotations.

3.2.3 Message Annotations

<type name="message-annotations" class="restricted" source="annotations" provides="section"> <descriptor name="amqp:message-annotations:map" code="0x00000000:0x00000072"/> </type>

The message-annotations section is used for properties of the message which are aimed at the infrastructure and SHOULD be propagated across every delivery step. Message annotations convey information about the message. Intermediaries MUST propagate the annotations unless the annotations are explicitly augmented or modified (e.g., by the use of the modified outcome).

The capabilities negotiated on link attach and on the source and target can be used to establish which annotations a peer understands; however, in a network of AMQP intermediaries it might not be possible to know if every intermediary will understand the annotation. Note that for some annotations it might not be necessary for the intermediary to understand their purpose, i.e., they could be used purely as an attribute which can be filtered on.

A registry of defined annotations and their meanings is maintained [AMQPMESSANN].

If the message-annotations section is omitted, it is equivalent to a message-annotations section containing an empty map of annotations.

3.2.4 Properties

Immutable properties of the message.

<type name="properties" class="composite" source="list" provides="section"> <descriptor name="amqp:properties:list" code="0x00000000:0x00000073"/> <field name="message-id" type="*" requires="message-id"/> <field name="user-id" type="binary"/> <field name="to" type="*" requires="address"/> <field name="subject" type="string"/> <field name="reply-to" type="*" requires="address"/> <field name="correlation-id" type="*" requires="message-id"/> <field name="content-type" type="symbol"/> <field name="content-encoding" type="symbol"/> <field name="absolute-expiry-time" type="timestamp"/> <field name="creation-time" type="timestamp"/> <field name="group-id" type="string"/> <field name="group-sequence" type="sequence-no"/> <field name="reply-to-group-id" type="string"/> </type>

The properties section is used for a defined set of standard properties of the message. The properties section is part of the bare message; therefore, if retransmitted by an intermediary, it MUST remain unaltered.

message-idapplication message identifieroptional *

Message-id, if set, uniquely identifies a message within the message system. The message producer is usually responsible for setting the message-id in such a way that it is assured to be globally unique. A broker MAY discard a message as a duplicate if the value of the message-id matches that of a previously received message sent to the same node.

user-idcreating user idoptional binary

The identity of the user responsible for producing the message. The client sets this value, and it MAY be authenticated by intermediaries.

tothe address of the node the message is destined foroptional *

The to field identifies the node that is the intended destination of the message. On any given transfer this might not be the node at the receiving end of the link.

subjectthe subject of the messageoptional string

A common field for summary information about the message content and purpose.

reply-tothe node to send replies tooptional *

The address of the node to send replies to.

correlation-idapplication correlation identifieroptional *

This is a client-specific id that can be used to mark or identify messages between clients.

content-typeMIME content typeoptional symbol

The RFC-2046 [RFC2046] MIME type for the message's application-data section (body). As per RFC-2046 [RFC2046] this can contain a charset parameter defining the character encoding used: e.g., 'text/plain; charset="utf-8"'.

For clarity, as per section 7.2.1 of RFC-2616 [RFC2616], where the content type is unknown the content-type SHOULD NOT be set. This allows the recipient the opportunity to determine the actual type. Where the section is known to be truly opaque binary data, the content-type SHOULD be set to application/octet-stream.

When using an application-data section with a section code other than data, content-type SHOULD NOT be set.

content-encodingMIME content typeoptional symbol

The content-encoding property is used as a modifier to the content-type. When present, its value indicates what additional content encodings have been applied to the application-data, and thus what decoding mechanisms need to be applied in order to obtain the media-type referenced by the content-type header field.

Content-encoding is primarily used to allow a document to be compressed without losing the identity of its underlying content type.

Content-encodings are to be interpreted as per section 3.5 of RFC 2616 [RFC2616]. Valid content-encodings are registered at IANA [IANAHTTPPARAMS].

The content-encoding MUST NOT be set when the application-data section is other than data. The binary representation of all other application-data section types is defined completely in terms of the AMQP type system.

Implementations MUST NOT use the identity encoding. Instead, implementations SHOULD NOT set this property. Implementations SHOULD NOT use the compress encoding, except as to remain compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.

Implementations SHOULD NOT specify multiple content-encoding values except as to be compatible with messages originally sent with other protocols, e.g. HTTP or SMTP.

absolute-expiry-timethe time when this message is considered expiredoptional timestamp

An absolute time when this message is considered to be expired.

creation-timethe time when this message was createdoptional timestamp

An absolute time when this message was created.

group-idthe group this message belongs tooptional string

Identifies the group the message belongs to.

group-sequencethe sequence-no of this message within its groupoptional sequence-no

The relative position of this message within its group.

reply-to-group-idthe group the reply message belongs tooptional string

This is a client-specific id that is used so that client can send replies to this message to a specific group.

3.2.5 Application Properties

<type name="application-properties" class="restricted" source="map" provides="section"> <descriptor name="amqp:application-properties:map" code="0x00000000:0x00000074"/> </type>

The application-properties section is a part of the bare message used for structured application data. Intermediaries can use the data within this structure for the purposes of filtering or routing.

The keys of this map are restricted to be of type string (which excludes the possibility of a null key) and the values are restricted to be of simple types only, that is, excluding map, list, and array types.

3.2.6 Data

<type name="data" class="restricted" source="binary" provides="section"> <descriptor name="amqp:data:binary" code="0x00000000:0x00000075"/> </type>

A data section contains opaque binary data.

3.2.7 Amqp Sequence

<type name="amqp-sequence" class="restricted" source="list" provides="section"> <descriptor name="amqp:amqp-sequence:list" code="0x00000000:0x00000076"/> </type>

A sequence section contains an arbitrary number of structured data elements.

3.2.8 Amqp Value

<type name="amqp-value" class="restricted" source="*" provides="section"> <descriptor name="amqp:amqp-value:*" code="0x00000000:0x00000077"/> </type>

An amqp-value section contains a single AMQP value.

3.2.9 Footer

Transport footers for a message.

<type name="footer" class="restricted" source="annotations" provides="section"> <descriptor name="amqp:footer:map" code="0x00000000:0x00000078"/> </type>

The footer section is used for details about the message or delivery which can only be calculated or evaluated once the whole bare message has been constructed or seen (for example message hashes, HMACs, signatures and encryption details).

A registry of defined footers and their meanings is maintained [AMQPFOOTER].

3.2.10 Annotations

<type name="annotations" class="restricted" source="map"/>

The annotations type is a map where the keys are restricted to be of type symbol or of type ulong. All ulong keys, and all symbolic keys except those beginning with "x-" are reserved. Keys beginning with "x-opt-" MUST be ignored if not understood. On receiving an annotation key which is not understood, and which does not begin with "x-opt", the receiving AMQP container MUST detach the link with a not-implemented error.

3.2.11 Message Id Ulong

<type name="message-id-ulong" class="restricted" source="ulong" provides="message-id"/>

3.2.12 Message Id Uuid

<type name="message-id-uuid" class="restricted" source="uuid" provides="message-id"/>

3.2.13 Message Id Binary

<type name="message-id-binary" class="restricted" source="binary" provides="message-id"/>

3.2.14 Message Id String

<type name="message-id-string" class="restricted" source="string" provides="message-id"/>

3.2.15 Address String

Address of a node.

<type name="address-string" class="restricted" source="string" provides="address"/>

3.2.16 Constant Definitions

MESSAGE-FORMAT0the format + revision for the messages defined by this document.

This value goes into the message-format field of the transfer frame when transferring messages of the format defined herein.

3.3 Distribution Nodes

The messaging layer defines a set of states for a distribution node, defined as a node that stores messages for distribution. Not all nodes are distribution nodes; however, these definitions permit some standardized interaction with those nodes that do. The transitions between these states are controlled by the transfer of messages to/from a distribution node and the resulting terminal delivery state. Note that the state of a message at one distribution node does not affect the state of the same message at a separate node.

By default a message will begin in the AVAILABLE state. Prior to initiating an acquiring transfer, the message will transition to the ACQUIRED state. Once in the ACQUIRED state, a message is ineligible for acquiring transfers to any other links.

A message will remain ACQUIRED at the distribution node until the transfer is settled. The delivery state at the receiver determines how the message transitions when the transfer is settled. If the delivery state at the receiver is not yet known, (e.g., the link endpoint is destroyed before recovery occurs) the default-outcome of the source is used (see source).

State transitions can also occur spontaneously at the distribution node. For example if a message with a ttl expires, the effect of expiry might be (depending on specific type and configuration of the distribution node) to move spontaneously from the AVAILABLE state into the ARCHIVED state. In this case any transfers of the message are transitioned to a terminal outcome at the distribution node regardless of receiver state.

Figure 3.1: Message State Transitions
+------------+ +->| AVAILABLE | | +------------+ | | | | terminal outcome: | | RELEASED/MODIFIED | | TRANSFER (acquiring) | | | | | \|/ | +------------+ +--| ACQUIRED | +------------+ | | | terminal outcome: | ACCEPTED/REJECTED | | \|/ +------------+ | ARCHIVED | +------------+

3.4 Delivery State

The messaging layer defines a concrete set of delivery states which can be used (via the disposition frame) to indicate the state of the message at the receiver. Delivery states can be either terminal or non-terminal. Once a delivery reaches a terminal delivery state, the state for that delivery will no longer change. A terminal delivery state is referred to as an outcome.

The following outcomes are formally defined by the messaging layer to indicate the result of processing at the receiver:

The following non-terminal delivery-state is formally defined by the messaging layer for use during link recovery to allow the sender to resume the transfer of a large message without retransmitting all the message data:

3.4.1 Received

<type name="received" class="composite" source="list" provides="delivery-state"> <descriptor name="amqp:received:list" code="0x00000000:0x00000023"/> <field name="section-number" type="uint" mandatory="true"/> <field name="section-offset" type="ulong" mandatory="true"/> </type>

At the target the received state indicates the furthest point in the payload of the message which the target will not need to have resent if the link is resumed. At the source the received state represents the earliest point in the payload which the sender is able to resume transferring at in the case of link resumption. When resuming a delivery, if this state is set on the first transfer performative it indicates the offset in the payload at which the first resumed delivery is starting. The sender MUST NOT send the received state on transfer or disposition performatives except on the first transfer performative on a resumed delivery.

section-numbermandatory uint

When sent by the sender this indicates the first section of the message (with section-number 0 being the first section) for which data can be resent. Data from sections prior to the given section cannot be retransmitted for this delivery.

When sent by the receiver this indicates the first section of the message for which all data might not yet have been received.

section-offsetmandatory ulong

When sent by the sender this indicates the first byte of the encoded section data of the section given by section-number for which data can be resent (with section-offset 0 being the first byte). Bytes from the same section prior to the given offset section cannot be retransmitted for this delivery.

When sent by the receiver this indicates the first byte of the given section which has not yet been received. Note that if a receiver has received all of section number X (which contains N bytes of data), but none of section number X + 1, then it can indicate this by sending either Received(section-number=X, section-offset=N) or Received(section-number=X+1, section-offset=0). The state Received(section-number=0, section-offset=0) indicates that no message data at all has been transferred.

3.4.2 Accepted

The accepted outcome.

<type name="accepted" class="composite" source="list" provides="delivery-state, outcome"> <descriptor name="amqp:accepted:list" code="0x00000000:0x00000024"/> </type>

At the source the accepted state means that the message has been retired from the node, and transfer of payload data will not be able to be resumed if the link becomes suspended. A delivery can become accepted at the source even before all transfer frames have been sent, this does not imply that the remaining transfers for the delivery will not be sent - only the aborted flag on the transfer performative can be used to indicate a premature termination of the transfer.

At the target, the accepted outcome is used to indicate that an incoming message has been successfully processed, and that the receiver of the message is expecting the sender to transition the delivery to the accepted state at the source.

The accepted outcome does not increment the delivery-count in the header of the accepted message.

3.4.3 Rejected

The rejected outcome.

<type name="rejected" class="composite" source="list" provides="delivery-state, outcome"> <descriptor name="amqp:rejected:list" code="0x00000000:0x00000025"/> <field name="error" type="error"/> </type>

At the target, the rejected outcome is used to indicate that an incoming message is invalid and therefore unprocessable. The rejected outcome when applied to a message will cause the delivery-count to be incremented in the header of the rejected message.

At the source, the rejected outcome means that the target has informed the source that the message was rejected, and the source has taken the necessary action. The delivery SHOULD NOT ever spontaneously attain the rejected state at the source.

errorerror that caused the message to be rejectedoptional error

This field contains diagnostic information about the cause of the message rejection.

3.4.4 Released

The released outcome.

<type name="released" class="composite" source="list" provides="delivery-state, outcome"> <descriptor name="amqp:released:list" code="0x00000000:0x00000026"/> </type>

At the source the released outcome means that the message is no longer acquired by the receiver, and has been made available for (re-)delivery to the same or other targets receiving from the node. The message is unchanged at the node (i.e., the delivery-count of the header of the released message MUST NOT be incremented). As released is a terminal outcome, transfer of payload data will not be able to be resumed if the link becomes suspended. A delivery can become released at the source even before all transfer frames have been sent. This does not imply that the remaining transfers for the delivery will not be sent. The source MAY spontaneously attain the released outcome for a message (for example the source might implement some sort of time-bound acquisition lock, after which the acquisition of a message at a node is revoked to allow for delivery to an alternative consumer).

At the target, the released outcome is used to indicate that a given transfer was not and will not be acted upon.

3.4.5 Modified

The modified outcome.

<type name="modified" class="composite" source="list" provides="delivery-state, outcome"> <descriptor name="amqp:modified:list" code="0x00000000:0x00000027"/> <field name="delivery-failed" type="boolean"/> <field name="undeliverable-here" type="boolean"/> <field name="message-annotations" type="fields"/> </type>

At the source the modified outcome means that the message is no longer acquired by the receiver, and has been made available for (re-)delivery to the same or other targets receiving from the node. The message has been changed at the node in the ways indicated by the fields of the outcome. As modified is a terminal outcome, transfer of payload data will not be able to be resumed if the link becomes suspended. A delivery can become modified at the source even before all transfer frames have been sent. This does not imply that the remaining transfers for the delivery will not be sent. The source MAY spontaneously attain the modified outcome for a message (for example the source might implement some sort of time-bound acquisition lock, after which the acquisition of a message at a node is revoked to allow for delivery to an alternative consumer with the message modified in some way to denote the previous failed, e.g., with delivery-failed set to true).

At the target, the modified outcome is used to indicate that a given transfer was not and will not be acted upon, and that the message SHOULD be modified in the specified ways at the node.

delivery-failedcount the transfer as an unsuccessful delivery attemptoptional boolean

If the delivery-failed flag is set, any messages modified MUST have their delivery-count incremented.

undeliverable-hereprevent redeliveryoptional boolean

If the undeliverable-here is set, then any messages released MUST NOT be redelivered to the modifying link endpoint.

message-annotationsmessage attributesoptional fields

Map containing attributes to combine with the existing message-annotations held in the message's header section. Where the existing message-annotations of the message contain an entry with the same key as an entry in this field, the value in this field associated with that key replaces the one in the existing headers; where the existing message-annotations has no such value, the value in this map is added.

3.4.6 Resuming Deliveries Using Delivery States

subsection 2.6.13 provides the general scheme for how two endpoints can re-establish state after link resumption was provided. The concrete delivery states defined above allow for a more comprehensive set of examples of link resumption.

Peer Partner ======================================================================= ATTACH(name=N, handle=1, --+ +-- ATTACH(name=N, handle=2, role=sender, \ / role=receiver, source=X, \ / source=X, target=Y, x target=Y, unsettled= / \ unsettled= { 1 -> null, / \ { 2 -> Received(3,0), 2 -> null, <-+ +-> 3 -> Accepted, 3 -> null, 4 -> null, 4 -> null, 6 -> Received(2,0), 5 -> Received(0,200), 7 -> Received(0,100), 6 -> Received(1,150), 8 -> Accepted, 7 -> Received(0,500), 9 -> null, 8 -> Received(3,5), 11 -> Received(1,2000), 9 -> Received(2,0), 12 -> Accepted, 10 -> Accepted, 13 -> Released, 11 -> Accepted, 14 -> null } 12 -> Accepted, 13 -> Accepted, 14 -> Accepted } ----------------------------------------------------------------------- Key: Received(x,y) means Received(section-number=x, section-offset=y)

In this example, for delivery-tags 1 to 4 inclusive the sender indicates that it can resume sending from the start of the message.

For delivery-tag 1, the receiver has no record of the delivery. To preserve "exactly once" or "at least once" delivery guarantees, the sender MUST resend the message; however, the delivery is not being resumed (since the receiver does not remember the delivery tag) so transfers MUST NOT have the resume flag set to true. If the sender were to mark the transfers as resumes then they would be ignored at the receiver.

For delivery-tag 2, the receiver has retained some of the data making up the message, but not the whole. In order to complete the delivery the sender needs to resume sending from some point before or at the next position which the receiver is expecting.

TRANSFER(delivery-id=1, ----------> ** Append message data not ** delivery-tag=2, ** seen previously to delivery ** (1) state=Received(3,0), ** state. ** resume=true) { ** payload ** } (1) state could be a) null, meaning that the transfer is being resumed from the first byte of section number 0 (and the receiver MUST ignore all data up to the first position it has not previously received). b) Received with section number 0, 1 or 2 and an offset, indicating that the payload data on the first frame of the resumed delivery starts at the given point, and that the receiver MUST ignore all data up to the first position it has not previously received. c) Received(3,0) indicating that the resumption will start at the first point which the receiver has not previously received.

For delivery-tag 3, the receiver indicates that it has processed the delivery to the point where it desires a terminal outcome (in this case accepted). In this case the sender will either apply that outcome at the source, or in the rare case that it cannot apply that outcome, indicate the terminal outcome that has been applied. To do this the sender MUST send a resuming transfer to associate delivery-tag 3 with a delivery-id. On this transfer the sender SHOULD set the delivery-state at the source. If this is the same outcome as at the receiver then the sender MAY also send the resuming transfer as settled.

TRANSFER(delivery-id=2, ----------> ** Processes confirmation that ** delivery-tag=3, ** was accepted, and settles. ** settled=true, more=false, state=Accepted, resume=true)

For delivery-tag 4, the receiver indicates that it is aware that the delivery had begun, but does not provide any indication that it has retained any data about that delivery except the fact of its existence. To preserve "exactly once" or "at least once" delivery guarantees, the sender MUST resend the whole message. Unlike the case with delivery-tag 1 the resent delivery MUST be sent with the resume flag set to true and the delivery-tag set to 4. (While this use of null in the receivers map is valid, it is discouraged. It is RECOMMENDED that receiver SHOULD NOT retain such an entry in its map, in which case the situation would be as for delivery-tag 1 in this example).

TRANSFER(delivery-id=3, ----------> ** Processes in the same way ** delivery-tag=4, ** as we be done for a non- ** (1) state=null, ** resumed delivery. ** resume=true) { ** payload ** } (1) Alternatively (and equivalently) state could be Received(section-number=0, section-offset=0)

For delivery-tags 5 to 9 inclusive the sender indicates that it can resume at some point beyond start of the message data. This is usually indicative of the fact that the receiver had previously confirmed reception of message data to the given point, removing responsibility from the sender to retain the ability to resend that data after resuming the link. The sender MAY still retain the ability to resend the message as a new delivery (i.e. it MAY not have completely discarded the data from which the original delivery was generated).

For delivery-tag 5, the receiver has no record of the delivery. To preserve "exactly once" or "at least once" delivery guarantees, the sender MUST resend the message; however, the delivery is not being resumed (since the receiver does not remember the delivery tag) so transfers MUST NOT have the resume flag set to true. If the sender does not have enough data to resend the message, then the sender MAY take some action to indicate that it believes there is a possibility that there has been message loss, for example, notify the application.

For delivery-tag 6, the receiver has retained some of the data making up the message, but not the whole. The first position within the message which the receiver has not received is after the first position at which the sender can resume sending. In order to complete the delivery the sender needs to resume sending from some point before or at the next position which the receiver is expecting.

TRANSFER(delivery-id=4, ----------> ** Append message data not ** delivery-tag=6, ** seen previously to delivery ** (1) state=Received(2,0), ** state. ** resume=true) { ** payload ** } (1) state could be any point between Received(1,150) and Received(2,0) inclusive. The receiver MUST ignore all data up to the first position it has not previously received (i.e. section 2 offset 0).

For delivery-tag 7, the receiver has retained some of the data making up the message, but not the whole. The first position within the message which the receiver has not received is before the first position at which the sender can resume sending. It is thus not possible for the sender to resume sending the message to completion. The only option available to the sender is to abort the transfer and to then (if possible) resend as a new delivery or else to report the possible message loss in some way if it cannot.

TRANSFER(delivery-id=5, ----------> ** Discard any state relating ** delivery-tag=7, ** to the message delivery. ** resume=true, aborted=true)

For delivery-tag 8, the receiver indicates that it has processed the delivery to the point where it desires a terminal outcome (in this case accepted). This is the same case as for delivery-tag 3.

TRANSFER(delivery-id=6, ----------> ** Processes confirmation that ** delivery-tag=8, ** was accepted, and settles. ** settled=true, more=false, state=Accepted, resume=true)

For delivery-tag 9, the receiver indicates that it is aware that the delivery had begun, but does not provide any indication that it has retained any data about that delivery except the fact of its existence. This is the same case as for delivery-tag 7.

TRANSFER(delivery-id=7, ----------> ** Discard any state relating ** delivery-tag=9, ** to the message delivery. ** resume=true, aborted=true)

For delivery-tags 10 to 14 inclusive the sender indicates that it has reached a terminal outcome, namely accepted. Once the sender has arrived at a terminal outcome it MUST NOT change. As such, if a sender is capable of resuming a delivery (even if the only possible outcome of the delivery is a pre-defined terminal outcome such as accepted) it MUST NOT use this state as the value of the state in its unsettled map until it is sure that the receiver will not require the resending of the message data.

For delivery-tag 10 the receiver has no record of the delivery. However, in contrast to the cases of delivery-tag 1 and delivery-tag 5, since it is known that the sender can only have arrived at this state through knowing that the receiver has received the whole message (or that the sender had spontaneously reached a terminal outcome with no possibility of resumption) there is no need to resend the message.

For delivery-tag 11 it MUST be assumed that the sender spontaneously attained the terminal outcome (and is unable to resume). In this case the sender can simply abort the delivery as it cannot be resumed.

TRANSFER(delivery-id=8, ----------> ** Discard any state relating ** delivery-tag=11, ** to the message delivery. ** resume=true, aborted=true)

For delivery-tag 12 both the sender and receiver have attained the same view of the terminal outcome, but neither has settled. In this case the sender SHOULD simply settle the delivery.

TRANSFER(delivery-id=9, ----------> ** Locally settle the delivery ** delivery-tag=12, settled=true, resume=true)

For delivery-tag 13 the sender and receiver have both attained terminal outcomes, but the outcomes differ. In this case, since the outcome actually takes effect at the sender, it is the sender's view that is definitive. The sender thus MUST restate this as the terminal outcome, and the receiver SHOULD then echo this and settle.

TRANSFER(delivery-id=10 ----------> ** Update any state affected ** delivery-tag=13, ** by the actual outcome, then ** settled=false, ** settle the delivery ** state=Accepted resume=true) <---------- DISPOSITION(first=10, last=10, state=Accepted, settled=true)

For delivery-tag 14 the case is essentially the same as for delivery-tag 11, as the null state at the receiver is essentially identical to having the state Received with section-number=0 and section-offset=0.

TRANSFER(delivery-id=11, ----------> ** Discard any state relating ** delivery-tag=14, ** to the message delivery. ** resume=true, aborted=true)

3.5 Sources and Targets

The messaging layer defines two concrete types (source and target) to be used as the source and target of a link. These types are supplied in the source and target fields of the attach frame when establishing or resuming link. The source is comprised of an address (which the container of the outgoing link endpoint will resolve to a node within that container) coupled with properties which determine:

3.5.1 Filtering Messages

A source can restrict the messages transferred from a source by specifying a filter. A filter can be thought of as a function which takes a message as input and returns a boolean value: true if the message will be accepted by the source, false otherwise. A filter MUST NOT change its return value for a message unless the state or annotations on the message at the node change (e.g., through an updated delivery state).

3.5.2 Distribution Modes

The source optionally defines a distribution-mode that informs and/or indicates how distribution nodes are to behave with respect to the link. The distribution-mode of a source determines how messages from a distribution node are distributed among its associated links. There are two defined distribution-modes: move and copy. When specified, the distribution-mode has two related effects on the behavior of a distribution node with respect to the link associated with the source.

The move distribution-mode causes messages transferred from the distribution node to transition to the ACQUIRED state prior to transfer over the link, and subsequently to the ARCHIVED state when the transfer is settled with a successful outcome. The copy distribution-mode leaves the state of the message unchanged at the distribution node.

A source MUST NOT resend a message which has previously been successfully transferred from the source, i.e., reached an ACCEPTED delivery state at the receiver. For a move link with a default configuration this is trivially achieved as such an end result will lead to the message in the ARCHIVED state on the node, and thus ineligible for transfer. For a copy link, state MUST be retained at the source to ensure compliance. In practice, for nodes which maintain a strict order on messages at the node, the state might simply be a record of the most recent message transferred.

A registry of commonly defined non-standard distribution-modes and their meanings is maintained [AMQPDISTMODE].

3.5.3 Source

<type name="source" class="composite" source="list" provides="source"> <descriptor name="amqp:source:list" code="0x00000000:0x00000028"/> <field name="address" type="*" requires="address"/> <field name="durable" type="terminus-durability" default="none"/> <field name="expiry-policy" type="terminus-expiry-policy" default="session-end"/> <field name="timeout" type="seconds" default="0"/> <field name="dynamic" type="boolean" default="false"/> <field name="dynamic-node-properties" type="node-properties"/> <field name="distribution-mode" type="symbol" requires="distribution-mode"/> <field name="filter" type="filter-set"/> <field name="default-outcome" type="*" requires="outcome"/> <field name="outcomes" type="symbol" multiple="true"/> <field name="capabilities" type="symbol" multiple="true"/> </type>

For containers which do not implement address resolution (and do not admit spontaneous link attachment from their partners) but are instead only used as producers of messages, it is unnecessary to provide spurious detail on the source. For this purpose it is possible to use a "minimal" source in which all the fields are left unset.

addressthe address of the sourceoptional *

The address of the source MUST NOT be set when sent on a attach frame sent by the receiving link endpoint where the dynamic flag is set to true (that is where the receiver is requesting the sender to create an addressable node).

The address of the source MUST be set when sent on a attach frame sent by the sending link endpoint where the dynamic flag is set to true (that is where the sender has created an addressable node at the request of the receiver and is now communicating the address of that created node). The generated name of the address SHOULD include the link name and the container-id of the remote container to allow for ease of identification.

durableindicates the durability of the terminusoptional terminus-durability

Indicates what state of the terminus will be retained durably: the state of durable messages, only existence and configuration of the terminus, or no state at all.

expiry-policythe expiry policy of the sourceoptional terminus-expiry-policy
timeoutduration that an expiring source will be retainedoptional seconds

The source starts expiring as indicated by the expiry-policy.

dynamicrequest dynamic creation of a remote nodeoptional boolean

When set to true by the receiving link endpoint, this field constitutes a request for the sending peer to dynamically create a node at the source. In this case the address field MUST NOT be set.

When set to true by the sending link endpoint this field indicates creation of a dynamically created node. In this case the address field will contain the address of the created node. The generated address SHOULD include the link name and other available information on the initiator of the request (such as the remote container-id) in some recognizable form for ease of traceability.

dynamic-node-propertiesproperties of the dynamically created nodeoptional node-properties

If the dynamic field is not set to true this field MUST be left unset.

When set by the receiving link endpoint, this field contains the desired properties of the node the receiver wishes to be created. When set by the sending link endpoint this field contains the actual properties of the dynamically created node. See subsection 3.5.9 for standard node properties. A registry of other commonly used node-properties and their meanings is maintained [AMQPNODEPROP].

distribution-modethe distribution mode of the linkoptional symbol

This field MUST be set by the sending end of the link if the endpoint supports more than one distribution-mode. This field MAY be set by the receiving end of the link to indicate a preference when a node supports multiple distribution modes.

filtera set of predicates to filter the messages admitted onto the linkoptional filter-set

See subsection 3.5.8. The receiving endpoint sets its desired filter, the sending endpoint sets the filter actually in place (including any filters defaulted at the node). The receiving endpoint MUST check that the filter in place meets its needs and take responsibility for detaching if it does not.

default-outcomedefault outcome for unsettled transfersoptional *

Indicates the outcome to be used for transfers that have not reached a terminal state at the receiver when the transfer is settled, including when the source is destroyed. The value MUST be a valid outcome (e.g., released or rejected).

outcomesdescriptors for the outcomes that can be chosen on this linkoptional symbol[]

The values in this field are the symbolic descriptors of the outcomes that can be chosen on this link. This field MAY be empty, indicating that the default-outcome will be assumed for all message transfers (if the default-outcome is not set, and no outcomes are provided, then the accepted outcome MUST be supported by the source).

When present, the values MUST be a symbolic descriptor of a valid outcome, e.g., "amqp:accepted:list".

capabilitiesthe extension capabilities the sender supports/desiresoptional symbol[]

A registry of commonly defined source capabilities and their meanings is maintained [AMQPSOURCECAP].

3.5.4 Target

<type name="target" class="composite" source="list" provides="target"> <descriptor name="amqp:target:list" code="0x00000000:0x00000029"/> <field name="address" type="*" requires="address"/> <field name="durable" type="terminus-durability" default="none"/> <field name="expiry-policy" type="terminus-expiry-policy" default="session-end"/> <field name="timeout" type="seconds" default="0"/> <field name="dynamic" type="boolean" default="false"/> <field name="dynamic-node-properties" type="node-properties"/> <field name="capabilities" type="symbol" multiple="true"/> </type>

For containers which do not implement address resolution (and do not admit spontaneous link attachment from their partners) but are instead only used as consumers of messages, it is unnecessary to provide spurious detail on the source. For this purpose it is possible to use a "minimal" target in which all the fields are left unset.

addressThe address of the target.optional *

The address of the target MUST NOT be set when sent on a attach frame sent by the sending link endpoint where the dynamic flag is set to true (that is where the sender is requesting the receiver to create an addressable node).

The address of the source MUST be set when sent on a attach frame sent by the receiving link endpoint where the dynamic flag is set to true (that is where the receiver has created an addressable node at the request of the sender and is now communicating the address of that created node). The generated name of the address SHOULD include the link name and the container-id of the remote container to allow for ease of identification.

durableindicates the durability of the terminusoptional terminus-durability

Indicates what state of the terminus will be retained durably: the state of durable messages, only existence and configuration of the terminus, or no state at all.

expiry-policythe expiry policy of the targetoptional terminus-expiry-policy
timeoutduration that an expiring target will be retainedoptional seconds

The target starts expiring as indicated by the expiry-policy.

dynamicrequest dynamic creation of a remote nodeoptional boolean

When set to true by the sending link endpoint, this field constitutes a request for the receiving peer to dynamically create a node at the target. In this case the address field MUST NOT be set.

When set to true by the receiving link endpoint this field indicates creation of a dynamically created node. In this case the address field will contain the address of the created node. The generated address SHOULD include the link name and other available information on the initiator of the request (such as the remote container-id) in some recognizable form for ease of traceability.

dynamic-node-propertiesproperties of the dynamically created nodeoptional node-properties

If the dynamic field is not set to true this field MUST be left unset.

When set by the sending link endpoint, this field contains the desired properties of the node the sender wishes to be created. When set by the receiving link endpoint this field contains the actual properties of the dynamically created node. See subsection 3.5.9 for standard node properties. A registry of other commonly used node-properties and their meanings is maintained [AMQPNODEPROP].

capabilitiesthe extension capabilities the sender supports/desiresoptional symbol[]

A registry of commonly defined target capabilities and their meanings is maintained [AMQPTARGETCAP].

3.5.5 Terminus Durability

Durability policy for a terminus.

<type name="terminus-durability" class="restricted" source="uint"> <choice name="none" value="0"/> <choice name="configuration" value="1"/> <choice name="unsettled-state" value="2"/> </type>

Determines which state of the terminus is held durably.

none0

No terminus state is retained durably.

configuration1

Only the existence and configuration of the terminus is retained durably.

unsettled-state2

In addition to the existence and configuration of the terminus, the unsettled state for durable messages is retained durably.

3.5.6 Terminus Expiry Policy

Expiry policy for a terminus.

<type name="terminus-expiry-policy" class="restricted" source="symbol"> <choice name="link-detach" value="link-detach"/> <choice name="session-end" value="session-end"/> <choice name="connection-close" value="connection-close"/> <choice name="never" value="never"/> </type>

Determines when the expiry timer of a terminus starts counting down from the timeout value. If the link is subsequently re-attached before the terminus is expired, then the count down is aborted. If the conditions for the terminus-expiry-policy are subsequently re-met, the expiry timer restarts from its originally configured timeout value.

link-detachlink-detach

The expiry timer starts when terminus is detached.

session-endsession-end

The expiry timer starts when the most recently associated session is ended.

connection-closeconnection-close

The expiry timer starts when most recently associated connection is closed.

nevernever

The terminus never expires.

3.5.7 Std Dist Mode

Link distribution policy.

<type name="std-dist-mode" class="restricted" source="symbol" provides="distribution-mode"> <choice name="move" value="move"/> <choice name="copy" value="copy"/> </type>

Policies for distributing messages when multiple links are connected to the same node.

movemove

once successfully transferred over the link, the message will no longer be available to other links from the same node

copycopy

once successfully transferred over the link, the message is still available for other links from the same node

3.5.8 Filter Set

<type name="filter-set" class="restricted" source="map"/>

A set of named filters. Every key in the map MUST be of type symbol, every value MUST be either null or of a described type which provides the archetype filter. A filter acts as a function on a message which returns a boolean result indicating whether the message can pass through that filter or not. A message will pass through a filter-set if and only if it passes through each of the named filters. If the value for a given key is null, this acts as if there were no such key present (i.e., all messages pass through the null filter).

Filter types are a defined extension point. The filter types that a given source supports will be indicated by the capabilities of the source. A registry of commonly defined filter types and their capabilities is maintained [AMQPFILTERS].

3.5.9 Node Properties

Properties of a node.

<type name="node-properties" class="restricted" source="fields"/>

A symbol-keyed map containing properties of a node used when requesting creation or reporting the creation of a dynamic node.

The following common properties are defined:

lifetime-policy

The lifetime of a dynamically generated node.

Definitionally, the lifetime will never be less than the lifetime of the link which caused its creation, however it is possible to extend the lifetime of dynamically created node using a lifetime policy. The value of this entry MUST be of a type which provides the lifetime-policy archetype. The following standard lifetime-policies are defined below: delete-on-close, delete-on-no-links, delete-on-no-messages or delete-on-no-links-or-messages.

supported-dist-modes

The distribution modes that the node supports.

The value of this entry MUST be one or more symbols which are valid distribution-modes. That is, the value MUST be of the same type as would be valid in a field defined with the following attributes:

type="symbol" multiple="true" requires="distribution-mode"

3.5.10 Delete On Close

Lifetime of dynamic node scoped to lifetime of link which caused creation.

<type name="delete-on-close" class="composite" source="list" provides="lifetime-policy"> <descriptor name="amqp:delete-on-close:list" code="0x00000000:0x0000002b"/> </type>

A node dynamically created with this lifetime policy will be deleted at the point that the link which caused its creation ceases to exist.

3.5.11 Delete On No Links

Lifetime of dynamic node scoped to existence of links to the node.

<type name="delete-on-no-links" class="composite" source="list" provides="lifetime-policy"> <descriptor name="amqp:delete-on-no-links:list" code="0x00000000:0x0000002c"/> </type>

A node dynamically created with this lifetime policy will be deleted at the point that there remain no links for which the node is either the source or target.

3.5.12 Delete On No Messages

Lifetime of dynamic node scoped to existence of messages on the node.

<type name="delete-on-no-messages" class="composite" source="list" provides="lifetime-policy"> <descriptor name="amqp:delete-on-no-messages:list" code="0x00000000:0x0000002d"/> </type>

A node dynamically created with this lifetime policy will be deleted at the point that the link which caused its creation no longer exists and there remain no messages at the node.

3.5.13 Delete On No Links Or Messages

Lifetime of node scoped to existence of messages on or links to the node.

<type name="delete-on-no-links-or-messages" class="composite" source="list" provides="lifetime-policy"> <descriptor name="amqp:delete-on-no-links-or-messages:list" code="0x00000000:0x0000002e"/> </type>

A node dynamically created with this lifetime policy will be deleted at the point that the there are no links which have this node as their source or target, and there remain no messages at the node.


<< Part 2: Transport Part 4: Transactions >>