Universal Messaging 10.7 | Concepts | AMQP | AMQP Guide | Delivery States | Terminal Delivery States
 
Terminal Delivery States
AMQP defines four terminal delivery states for message transfers that can occur after completion of the transfer: accepted, rejected, released and modified.
Accepted
The accepted terminal delivery state indicates that the destination node has accepted the transfer.
Accepted: Subscription Mapping
The following table illustrates how the accepted delivery state is mapped to Universal Messaging server (Sender) communicating with an AMQP subscriber (Receiver):
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
null
null
N/A
N/A
N/A
(tick)
Description: When UM receives a disposition frame without a local and remote state, it responds by accepting the delivery, disposing using the source's default outcome and advancing the link.
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
N/A
accepted
true
N/A
N/A
(tick)
Description: When UM receives a disposition frame with a remote state of accepted but already settled, no further action is taken.
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
N/A
accepted
false
ANY
ANY
(tick)
Description: When UM receives a link attachment the link address is examined and the destination node verified. Following that an asynchronous UM native sub is queued. Finally when the UM server has completed the subscription, the delivery is accepted and settled. This is equivalent to a UM regular subscribe.
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
N/A
accepted
false
ReceiverSettleMode.FIRST
NONE
(tick)
Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability NONE and ReceiverSettleMode.FIRST, it accepts and settles it with no further action. This is equivalent to a UM reliable subscriber (no durability, no ACKs).
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
N/A
accepted
false
ReceiverSettleMode.FIRST
CONFIGURATION OR UNSETTLED_STATE
(tick)
Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability CONFIGURATION (NON PERSISTENT) or UNSETTLED_STATE (PERSISTENT) and ReceiverSettleMode.FIRST, it first extracts the delivery tag which is expected in the form <um store uniqueid>:<um event EID>, followed by extracting the durable name from the link. Following that an asynchronous UM native ACK (SYNC=TRUE, INDIVIDUAL=TRUE) is queued with the mapped fields. Finally when the UM server has completed the ACK, the delivery is accepted and settled. This is equivalent to a UM durable subscriber ACK.
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
N/A
accepted
false
ReceiverSettleMode.SECOND
NONE
(tick)
Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability NONE and ReceiverSettleMode.FIRST, it accepts and settles it with no further action. This is equivalent to a UM reliable subscriber (no durability, no ACKs).
Note:
Normally in this mode, UM should use 2 phase commit semantics to communicate the acceptance before setting. As UM does not currently support 2 phase commit, this currently behaves exactly like ReceiverSettleMode.FIRST.
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
N/A
accepted
false
ReceiverSettleMode.SECOND
CONFIGURATION OR UNSETTLED_STATE
(tick)
Description: When UM receives an unsettled disposition frame with a remote state of accepted, durability CONFIGURATION or UNSETTLED_STATE and ReceiverSettleMode.FIRST, it first extracts the delivery tag which is expected in the form <um store uniqueid>:<um event EID>, followed by extracting the durable name from the link. Following that an asynchronous UM native ACK (SYNC=TRUE, INDIVIDUAL=TRUE) is queued with the mapped fields. Finally when the UM server has completed the ACK, the delivery is accepted and settled. This is equivalent to a UM durable subscriber ACK.
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
N/A
transactional
N/A
N/A
N/A
(tick)
Description: When UM receives an unsettled disposition frame with a remote state of transactional, it first extracts the delivery tag which is expected in the form <um store uniqueid>:<um event EID>, followed by extracting the durable name from the link. Following that it updates internal data structures in the sender session context. This is equivalent to a UM transactional durable subscriber ACK.
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
UM 10.7
null
null
N/A
N/A
N/A
(tick)
When UM receives a disposition frame without a local and remote state, it responds by accepting the delivery, disposing using the source's default outcome and advancing the link.
Accepted: Publishing Mapping
The following table illustrates how the accepted delivery state is mapped to a Universal Messaging server (Receiver) communicating with an AMQP publisher (Sender):
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
UM 10.7
true
null
N/A
N/A
(error)
Description: When UM receives a partial delivery, it rejects it with an amqp:not-implemented error and settles, as multi frame transfers are not currently supported in UM. We have plans to add support for this in a future release of the product.
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
UM 10.7
false
N/A
null
N/A
(tick)
Description: When UM receives a non-partial delivery it tries to examine and transform its contents using the configured UM transformer. If the result of this operation is null, the delivery is rejected with an amqp:precondition-failed error and settled. This is unexpected outcome which indicates that an unexpected error occurred during transformation.
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
UM 10.7
false
NOT transactional
NOT null
SETTLED
(tick)
Description: When UM receives a non-partial and non-transactional delivery it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM native publish is queued. Finally, when the UM server has processed the native publish and Sender Settle mode is SETTLED, no further action is taken. This is directly equivalent to a UM reliable publisher.
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
UM 10.7
false
NOT transactional
NOT null
UNSETTLED
(tick)
Description: When UM receives a non-partial and non-transactional delivery it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM native publish is queued. Finally, when the UM server has processed the native publish and Sender Settle mode is UNSETTLED, it will accept it and advance the link. This is equivalent to a UM reliable publisher with a response from the server but no transactions.
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
UM 10.7
false
NOT transactional
NOT null
MIXED
(tick)
Description: When UM receives a non-partial and non-transactional delivery it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM native publish is queued. Finally, when the UM server has processed the native publish and Sender Settle mode is MIXED, it will accept it and advance the link ONLY if it is not already settled. This is equivalent to a UM reliable publisher with a response from the server for some publisher controlled transfers and no transactions involved.
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
UM 10.7
false
transactional
NOT null
N/A
(tick)
Description: When UM receives a non-partial delivery transactional delivery, it tries to examine and transform its contents using the configured UM transformer. Following that, an asynchronous UM TX native publish request is queued. Finally, when the UM server has processed the native TX publish request, it will accept it with a transaction state set to the TX ID and advance the link ONLY if it is not already settled. If it is already settled, no further action will be taken. This is equivalent to a UM TX publisher .
Rejected
The rejected terminal delivery state indicates that the destination node has rejected the transfer.
Subscription Mapping
The following table illustrates how the rejected delivery state is mapped to Universal Messaging server (Sender) communicating with an AMQP subscriber (Receiver):
Local Disposition State
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
AMQP Errors
UM 10.7
N/A
accepted
false
ANY
ANY
amqp:unauthorized-access (fatal)
amqp:internal-error (fatal)
amqp:not-found (fatal)
amqp:invalid-field (fatal)
amqp:illegal-state (fatal)
(tick)
As discussed in the accepted state mappings, an AMQP subscriber with these settings is mapped to an asynchronous UM native subscription. When the UM server has completed processing the subscription request and an error has occurred the delivery is rejected and settled as follows:
*amqp:unauthorized-access : UM ACLs do not allow subscriptions for this subject. This is a fatal error so the link is closed.
*amqp:internal-error: An unexpected UM internal error has occurred. This is a fatal error so the link is closed.
*amqp:not-found: The UM server is unable to find the destination node. This is fatal error so the link is closed.
*amqp:invalid-field: The message selector specified under key jms-selector raised a selector parse error.
*amqp:illegal-state: The UM server rejected the subscription because the connection is already subscribed.
Remote Disposition State
Delivery Settled
Receiver Settle Mode
Source Durability
AMQP Errors
UM 10.7
accepted
false
ReceiverSettleMode.FIRST
OR
ReceiverSettleMode.SECOND
CONFIGURATION
OR
UNSETTLED_STATE
amqp:unauthorized-access (fatal)
amqp:not-found (fatal)
(tick)
In addition to the above rejections applying for all subscriptions and accepted state mappings, an AMQP subscriber with these settings is mapped to an asynchronous UM native ACK (SYNC=TRUE, INDIVIDUAL=TRUE). When the UM server has completed processing the ACK, and an error has occurred the delivery is rejected and settled as follows:
*amqp:unauthorized-access : UM ACLs do not allow durable subscribing for this subject. This is a fatal error so the link is closed.
*amqp:not-found: The UM server is unable to find the durable name on the destination node. This is fatal error so the link is closed.
Publishing Mapping
The following table illustrates how the rejected delivery state is mapped to a Universal Messaging server (Receiver) communicating with an AMQP publisher (Sender):
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
AMQP Errors
UM 10.7
true
null
N/A
N/A
amqp:not-implemented (fatal)
(tick)
Description: When UM receives a partial delivery, it rejects it and settles it, as multi frame transfers are not currently supported in UM. We have plans to add support for this in a future release of the product.
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
AMQP Errors
UM 10.7
false
NOT transactional
NOT null
UNSETTLED OR SETTLED
amqp:unauthorized-access (fatal)
amqp:resource-limit-exceeded (transient)
amqp:internal-error (fatal)
amqp:not-found (fatal)
(tick)
Description: As discussed in the accepted state mappings, an AMQP publisher with these settings is mapped to an asynchronous UM native publish getting queued. When the UM server has completed processing the native publish, and an error has occurred the delivery is rejected and settled as follows:
*amqp:unauthorized-access : UM ACLs do not allow publishing for this subject. This is a fatal error so the link is closed.
*amqp:resource-limit-exceeded: UM store capacity has been reached. This is a transient error so the link is advanced.
*amqp:internal-error: An unexpected UM internal error has occurred. This is a fatal error so the link is closed.
*amqp:not-found: The UM server is unable to find the destination node. This is fatal error so the link is closed.
Partial Delivery
Remote Disposition State
UM Transformer Result
Sender Settle Mode
AMQP Errors
UM 10.7
false
transactional
NOT null
N/A
amqp:unauthorized-access (fatal)
amqp:resource-limit-exceeded (transient)
amqp:internal-error (fatal)
amqp:not-found (fatal)
(tick)
Description: As discussed in the accepted state mappings, a transactional AMQP publisher with these settings is mapped to an asynchronous UM TX native publish request getting queued. When the UM server has completed processing the native TX publish request, and an error has occurred, the delivery is rejected and settled as follows:
*amqp:unauthorized-access : UM ACLs do not allow publishing for this subject. This is a fatal error so the link is closed.
*amqp:resource-limit-exceeded: UM store capacity has been reached. This is a transient error so the link is advanced.
*amqp:internal-error: An unexpected UM internal error has occurred. This is a fatal error so the link is closed.
*amqp:not-found: The UM server is unable to find the destination node. This is fatal error so the link is closed.
Released
The released terminal delivery state indicates that the destination node no longer knows anything about the transfer, expecting redelivery.
NOTE: In Universal Messaging Link no explicit use of the released state is performed as it is internally handled by the Apache Qpid™ Proton-J protocol engine. See https://qpid.apache.org/proton/index.html for related information.
Modified
The modified terminal delivery state indicates that the destination node no longer knows anything about the transfer, expecting redelivery but only after modification by the sender.
NOTE: In Universal Messaging Link no explicit use of the modified state is performed as it is internally handled by the Apache Qpid™ Proton-J protocol engine. See https://qpid.apache.org/proton/index.html for related information.