[OASIS Issue Tracker] (AMQP-141) Guidance required for the use of dispositions in a multi-node AMQP network

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Keith Wall created AMQP-141:
-------------------------------

             Summary: Guidance required for the use of dispositions in a multi-node AMQP network
                 Key: AMQP-141
                 URL: https://issues.oasis-open.org/browse/AMQP-141
             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
          Issue Type: Task
         Environment: In a multi-node AMQP network where two or more nodes have store and forward capabilities (i.e. are brokers), there is an issue relating to the use of dispositions that doesn't appear with a simple client/server relationship. 

Consider the following AMQP networking comprising two AMQP applications and two intermediary AMQP brokers.  Here a message is produced by app1, enqueued by broker1, dequeued/forwarded to broker2 where it is enqueued again, and finally consumed by app2.

app1 Â-> broker1 -> broker2 -> app2

If broker2 for some reason needs to refuse the message owing to a transient condition (such as queue full) this is signalled using a disposition perfomative.    A approach common amongst existing AMQP implementations is to use the Rejected [1] outcome using the error-condition to indicate the underlying cause "queue full".   However, Reject is defined "incoming message is invalid and therefore unprocessable" so a conforming AMQP implementation can simply drop the message, meaning the message is lost from the network.

The problem is not apparent in a simple client/server scenario as the sending application usually has sufficient information to recreate the message from scratch on receipt of the Reject.  With the topology described above, with intermediate queues, this is not an option.

[1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-rejected

Guidance in the form of a technical note would be help the AMQP 1.0 implementing community.


Â

Â

Â

Â

Â

Â

Â
            Reporter: Keith Wall






--
This message was sent by Atlassian JIRA
(v7.7.2#77003)