Bug 981642

Summary: provide means of configuring subscription queue when subscribing to an exchange over amqp 1.0
Product: Red Hat Enterprise MRG Reporter: Gordon Sim <gsim>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED CURRENTRELEASE QA Contact: Zdenek Kraus <zkraus>
Severity: unspecified Docs Contact:
Priority: medium    
Version: DevelopmentCC: esammons, iboverma, jross, zkraus
Target Milestone: 3.0Keywords: Improvement
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-qmf-0.22-7 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-01-21 12:55:49 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:
Bug Depends On:    
Bug Blocks: 1010399    

Description Gordon Sim 2013-07-05 11:26:31 UTC
Description of problem:

The AMQP 1.0 protocol does not provide an obvious means of configuring the subscription. Capabilities can be requested but these are simple strings and don't lend themselves to e.g. specifying a maximum depth. Further, this is configuration that often makes sense to control in one place, at the broker, rather than trying to ensure clients themselves choose the right options.

The proposed solution is to allow 'topics' to be created. These give a name to an exchange paired with a set of queue configuration options. AMQP 1.0 links can be attached from (and to) these topics using their name and the subscription queue created will use the specified queue configuration parameters.

Steps to test:
1. create topic, e.g. using qpidt tool: 

qpidt create topic my-topic exchange=amq.fanout qpid.policy_type=ring qpid.max_count=10

2. Create your receiver using an address that referenced the topic created

E.g. qpid-receive --connection-options {protocol:amqp1.0} --address my-topic -f

Expected results:

There should now be a subscription queue bound to the amq.fanout exchange and it should have the specified configuration, e.g. in this case it should be a ring queue with a maximum of 50 messages.

Comment 1 Gordon Sim 2013-07-05 11:27:35 UTC
Fixed upstream by https://svn.apache.org/r1497036 and https://svn.apache.org/r1497074.

Comment 2 Zdenek Kraus 2014-03-25 06:56:01 UTC
Tested on RHEL 6.5 i686, x86_64, with following packages:

perl-qpid-0.22-11.el6
python-qpid-0.22-12.el6
python-qpid-qmf-0.22-28.el6
qpid-cpp-client-0.22-36.el6
qpid-cpp-client-devel-0.22-36.el6
qpid-cpp-client-devel-docs-0.22-36.el6
qpid-cpp-debuginfo-0.22-36.el6
qpid-cpp-server-0.22-36.el6
qpid-cpp-server-devel-0.22-36.el6
qpid-cpp-server-ha-0.22-36.el6
qpid-cpp-server-linearstore-0.22-36.el6
qpid-cpp-server-xml-0.22-36.el6
qpid-java-client-0.22-6.el6
qpid-java-common-0.22-6.el6
qpid-java-example-0.22-6.el6
qpid-jca-0.22-2.el6
qpid-jca-xarecovery-0.22-2.el6
qpid-proton-c-0.6-1.el6
qpid-proton-c-devel-0.6-1.el6
qpid-proton-debuginfo-0.6-1.el6
qpid-qmf-0.22-28.el6
qpid-qmf-debuginfo-0.22-28.el6
qpid-snmpd-1.0.0-16.el6
qpid-snmpd-debuginfo-1.0.0-16.el6
qpid-tools-0.22-9.el6
ruby-qpid-qmf-0.22-28.el6


-> VERIFIED