[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (AMQP-141) Guidance required for the use of dispositions in a multi-node AMQP network
[ https://issues.oasis-open.org/browse/AMQP-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Wall updated AMQP-141:
----------------------------
Description:
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 assuming broker1 is a conforming AMQP implementation the message is dropped and 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. However, with the topology described above, with intermediate queues, this is not an option; the original transfer from app1 to broker1 is already settled and broker1 is now the owner.
[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.
was:
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 assuming broker1 is a conforming AMQP implementation the message is dropped and 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.
> 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
> Reporter: Keith Wall
> Priority: Major
>
> 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 assuming broker1 is a conforming AMQP implementation the message is dropped and 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. However, with the topology described above, with intermediate queues, this is not an option; the original transfer from app1 to broker1 is already settled and broker1 is now the owner.
> [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.
--
This message was sent by Atlassian JIRA
(v7.7.2#77003)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]