OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

+1 that this needs clarification. The choice of terms (rejected, released, modified) is not at all clear.Â

My understanding is that using "rejected" to indicate a transient problem is incorrect - I agree that many implementations use it that way, it is easy to read the word "rejected" that way.Â

As the spec is written, you should use "released" or "modified' to indicate a transient problem.

"released" requests an "invisible" failure - the sender is not supposed to increase the delivery count or otherwise modify the message. I say "requests" because there is no actual mandated re-try behaviour for senders A sender that gets a released outcome can do anything it wants - retry, use timeouts or counters, give up, change the message, send it somewhere else, dump core etc.

"modified" requests the message be updated before re-sending - again there is no mandated retry behavior, and the sender can pretty much do what it likes, but modifying the message as requested before a re-send would be polite.

"rejected" means the message is ill-formed, which is not defined by this spec - it's some receiver-specific criteria. For the sender it means there's no point re-sending this message anywhere (at least anywhere with the same ill-formed criteria as the receiver that rejected it)

"rejected" is the most often used outcome and is usually used incorrectly.

On Mon, Sep 23, 2019 at 9:03 AM OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org> wrote:
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

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]