Bug 730981

Summary: Unable to create binding while sending messages on default exchange using addressing
Product: Red Hat Enterprise MRG Reporter: Petr Matousek <pematous>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED ERRATA QA Contact: Petr Matousek <pematous>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 2.0CC: gsim, iboverma, jross, tross
Target Milestone: 2.1.2   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-cpp-mrg-0.14-3.el5 Doc Type: Bug Fix
Doc Text:
Cause: Attempts to create a sender/receiver to/from a predefined exchange and utilise a create policy in the address in order to establish some node level bindings to it. Consequence: Such attempts failed due to the c++ client incorrectly trying to declare the predefined exchange without setting the passive flag as required by AMQP 0-10 for exchanges with reserved names. Fix: Exchanges with reserved names are now treated as special cases and the passive flag will always be set when declaring them as part of a create policy. Result: Attempts to establish bindings defined in the node section of an address whose named node is a predefined exchange will no longer fail.
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-30 17:51:59 UTC Type: ---
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: 783492    

Description Petr Matousek 2011-08-16 13:09:03 UTC
Description of problem:

./spout "amq.direct;{create: always,node:{type: topic,x-bindings: [{ exchange: 'amq.direct', queue: 'q', key: 'key' }]}}"
2011-08-16 16:03:51 warning Exception received from broker: not-allowed: not-allowed: Exchange names beginning with "amq." or "qpid." are reserved. (exchange="amq.direct") (qpid/broker/SessionAdapter.cpp:94) [caused by 1 \x07:\x01]
Create failed for exchange amq.direct; not-allowed: not-allowed: Exchange names beginning with "amq." or "qpid." are reserved. (exchange="amq.direct") (qpid/broker/SessionAdapter.cpp:94)
2011-08-16 16:03:51 warning Ignoring frame while closing connection: Frame[BEbe; channel=1; {SessionDetachBody: name=7f7a3962-b8b2-4176-8ea9-5cbdba5d741f; }]

Version-Release number of selected component (if applicable):
qpid-cpp-client-0.10-6

How reproducible:
100%

Steps to Reproduce:
1. qpid-config add queue q
2. spout "amq.direct;{create: always,node:{type: topic,x-bindings: [{ exchange: 'amq.direct', queue: 'q', key: 'key' }]}}"
3.
  
Actual results:
Not-allowed exception.

Expected results:
The binding specified in the address is created, message is sent on that address.

Additional info:

Comment 1 Gordon Sim 2011-08-16 17:03:56 UTC
Fixed upstream: http://svn.apache.org/viewvc?view=rev&rev=1158370

Comment 3 Petr Matousek 2011-12-21 10:59:53 UTC
This issue has been fixed.

Verified on RHEL5.7 and RHEL6.2, architectures: x86_64, i686 

packages installed:
qpid-cpp-mrg-0.14-3.el5
qpid-cpp-0.14-1.el6

-> VERIFIED

Comment 4 Gordon Sim 2012-03-06 18:24:23 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause:

  Attempts to create a sender/receiver to/from a predefined exchange and utilise a create policy in the address in order to establish some node level bindings to it.

Consequence:

  Such attempts failed due to the c++ client incorrectly trying to declare the predefined exchange without setting the passive flag as required by AMQP 0-10 for exchanges with reserved names.

Fix:

  Exchanges with reserved names are now treated as special cases and the passive flag will always be set when declaring them as part of a create policy.

Result:

  Attempts to establish bindings defined in the node section of an address whose named node is a predefined exchange will no longer fail.

Comment 5 errata-xmlrpc 2012-04-30 17:51:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0529.html