Description of problem: It is not possible to create binding on already existing exchanges/queues C++ client behaviour is correct and can be used as model. Version-Release number of selected component (if applicable): python-qpid-0.10-1.el6.noarch How reproducible: 100% Steps to Reproduce: 1. drain "q;{create: always,node:{type: queue}}" 2. spout "'amq.direct'/key;{ create: always, node: { type: topic, x-bindings: [{ exchange:'amq.direct', queue: 'q', key: 'key' }]}}" 3. qpid-config -b queues 4. the binding is not present NOTICE: If non-existing exchange instead of amq.direct is used , the binding is successfully created Actual results: The binding is not created if the already exist. Expected results: The binding is created even if the object already exists. Additional info:
*** Bug 841838 has been marked as a duplicate of this bug. ***
This is somehow questionable what the desired behaviour should be. Address string "q;{create: always,node:{type: queue, x-bindings: [{ exchange:'amq.fanou', queue: 'q'}]}}" asks for creating a queue with some parameters (of the node). If the node already exists, the work is already done. If I want to ensure binding is created, let use "link" instead of "node" object. On the other side, both clients (C++ and Python) should provide same behaviour. And it is easier - from users/customers point of view - to _extend_ missing functionality (in py) rather than _remove_ the functionality (in cpp). So I will propose a patch for this. (and likely put to review, to ensure others have the same feeling like me).
Also in review request: https://reviews.apache.org/r/22724/
Committed as r1603448.
Proposed doc text: It was discovered that the python client did not create binding from already existing queue, if it was ordered to create both. This caused the binding is not created. A change in the python client now ensures the binding will be created.
This issue has been fixed. The binding is created regardless if the node exists or not if create policy is used. The binding is also created regardless if specified in the link or node (due to be compliant w/ c++ client). Verified on rhel6.6 (x86_64 and i386) and rhel7.1 (x86_64). Packages: python-qpid-0.30-6 -> VERIFIED
Unfortunately, I have to re-open this bug, there is one more case that I missed before. It is possible that the fix is incomplete. Following three conditions must be met in order to reproduce the issue: 1. node type is not specified in the address string 2. the binding is defined within the node map the 3. exchange name is not specified in the x-bindings This probably results in empty exchange argument for the bind request and following exception (no message is sent): ie.: 1. ./drain -t 10 -c 1 "Q726695;{create:receiver}" 2. ./spout "amq.direct;{create:always, node: { x-bindings:[{queue:Q726695}] } }" 3. Traceback (most recent call last): File "/usr/share/doc/python-qpid-0.30/examples/api/spout", line 107, in <module> snd = ssn.sender(addr) File "<string>", line 6, in sender File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 617, in sender sender._ewait(lambda: sender.linked) File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 834, in _ewait result = self.session._ewait(lambda: self.error or predicate(), timeout) File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 592, in _ewait self.check_error() File "/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py", line 581, in check_error raise self.error qpid.messaging.exceptions.SessionError: invalid-argument: Bind not allowed for default exchange (/builddir/build/BUILD/qpid-cpp-0.30/src/qpid/broker/Broker.cpp:1579)(542) Although I agree that the binding shall be defined in the link, defining the binding in node works as well for C++ client. As stated in comment 2, this bug shall fix this discrepancy for python client. So, I think this is related to the fix. Using C++ client the message is sent to amq.direct, the binding is created and message is received on the queue Q726695 as expected. On the other hand this is a special case and probably also wrong use-case, as the binding shall be specified in the _link_ when receiving from exchange. If this has nothing with the supplied fix. it's discussable whether this needs to be addressed. Could you possibly confirm whether this is related to the fix or not and whether it needs to be addressed? If you feel that this is not connected to the supplied fix, I'm open to threat the issue as different bug.
In all the following cases behaviour is es expected (message is delivered): binding defined in the link: 2. ./spout "amq.direct;{create:always, link: { x-bindings:[{queue:Q726695}] } }" topic node type specified: 2. ./spout "amq.direct;{create:always, node: { type: topic, x-bindings:[{queue:Q726695}] } }" topic node type specified: 2. ./spout "amq.direct;{create:always, node: { x-bindings:[{exchange:'amq.direct', queue:Q726695}] } }" C++ client is used: 2. $cppapi/spout "amq.direct;{create:always, node: { x-bindings:[{queue:Q726695}] } }"
(In reply to Petr Matousek from comment #10) small correction: - topic node type specified: + Exchange name specified in the binding: 2. ./spout "amq.direct;{create:always, node: { x-bindings:[{exchange:'amq.direct', queue:Q726695}] } }"
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. https://rhn.redhat.com/errata/RHEA-2015-0805.html