Bug 1009982

Summary:	[amqp1.0] unsupported address string elements
Product:	Red Hat Enterprise MRG	Reporter:	Petr Matousek <pematous>
Component:	Messaging_Programming_Reference	Assignee:	Jared MORGAN <jmorgan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Matousek <pematous>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	Development	CC:	esammons, gsim, jross, mmurray
Target Milestone:	3.0
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-01-22 15:28:22 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Petr Matousek 2013-09-19 16:01:30 UTC

Description of problem:

Currently Following address string elements are not supported over AMQP 1.0:
Link scoped x-declare
Node scoped x-bindings
Link scoped x-bindings
Delete policies

also results of assert policies are different between protocols.

This is conflict with the "Address string compatibility" requirement for MRG Vienna.

I'm not aware if there is a plan to add translation support for these elements, thus raising this bug for qpid-cpp component.
If the plan is to not support these address string elements over amqp1.0 at all, please change the component to documentation and describe well how the lack of the support shall be handled over amqp1.0.

Version-Release number of selected component (if applicable):
qpid-cpp-*-0.22-14

How reproducible:
n/a

Steps to Reproduce:
1. use the above mentioned elements in the address string when using amqp1.0 protocol
2. not supported error message is displayed

Actual results:
several address string element are not supported over amqp1.0

Expected results:
Add the support to fulfill the address string compatibility or document how to deal with the lack of support

Comment 1 Gordon Sim 2013-09-25 16:12:09 UTC

At this point there is no plan to try to map these elements of the address. Any mechanism for doing so would likely be tied to qpidd and the objective behind adding 1.0 support is to allow interoperability with other implementations.

The 0-10 path remains supported, so there is no requirement for any application that cannot avoid using these elements to upgrade to AMQP 1.0 (and since they would be tied to qpidd if some scheme was implemented, the value of doing so would in any case be less clear).

Delete policies:

Instead of using a delete policy, specify the lifetime of the queue when creating it.

Link scoped x-declare:

Use a topic node (can be creates using qpid-tool or the qpidt utility, though the latter is not shipped) with the desired subscription queue properties configured and the exchange desired.

Link scoped x-bindings:

Use filters (only works when creating a receiver).

Node scoped x-bindings:

As for link scoped x-bindings, use filters in the link. If the node is a queue, change it to being the exchange to bind to.

Also, though they are supported, create policies are not recommended as they
use AMQP 1.0 in a non-standard manner. It is also recommended to only use assert policies for verifying filters and capabilities; i.e. not using assert in an address where node properties are specified as this too uses AMQP 1.0 in a non-standard manner.

Finally, though node a scoped x-declare will be translated automatically into a node properties map, direct use of the properties map is encouraged.

Comment 2 Joshua Wulf 2013-10-03 05:27:48 UTC

Incorporated into: http://deathstar1.usersys.redhat.com:3000/builds/19948-Messaging_Programming_Reference/#AMQP_1.0_support_in_MRG-M_3

Gordon, can you please take a look at that and let me know if this information is sufficiently incorporated / covered.

Comment 3 Gordon Sim 2013-10-04 12:48:37 UTC

Yes, I think so.

Comment 4 Petr Matousek 2013-10-15 08:18:17 UTC

Also Link scoped x-subscribe element not supported over AMQP 1.0.

Comment 6 Petr Matousek 2013-11-04 17:02:48 UTC

Content approved.

Version-Release number of selected component (if applicable):
Messaging Programming Reference - Revision 0.0.0-1 (Mon Nov 04 2013)

-> VERIFIED