Bug 726695 - Unable to create bindings on already existing broker objects using addressing
Summary: Unable to create bindings on already existing broker objects using addressing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: python-qpid
Version: 2.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: 3.1
: ---
Assignee: Pavel Moravec
QA Contact: Petr Matousek
URL:
Whiteboard:
: 841838 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-29 14:06 UTC by Petr Matousek
Modified: 2015-08-03 14:03 UTC (History)
4 users (show)

Fixed In Version: python-qpid-0.30-2
Doc Type: Bug Fix
Doc Text:
It was discovered that the python client did not create a binding from an already existing queue, if it was ordered to create both. Improvements to the python client now ensure the binding is created as expected.
Clone Of:
: 1207365 (view as bug list)
Environment:
Last Closed: 2015-04-14 13:46:04 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Apache JIRA QPID-5830 None None None Never
Red Hat Bugzilla 1249659 None None None Never
Red Hat Product Errata RHEA-2015:0805 normal SHIPPED_LIVE Red Hat Enterprise MRG Messaging 3.1 Release 2015-04-14 17:45:54 UTC

Internal Links: 1249659

Description Petr Matousek 2011-07-29 14:06:17 UTC
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:

Comment 1 Justin Ross 2013-02-27 11:35:02 UTC
*** Bug 841838 has been marked as a duplicate of this bug. ***

Comment 2 Pavel Moravec 2014-06-17 13:58:25 UTC
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).

Comment 3 Pavel Moravec 2014-06-18 11:07:58 UTC
Also in review request: https://reviews.apache.org/r/22724/

Comment 4 Pavel Moravec 2014-06-18 13:23:27 UTC
Committed as r1603448.

Comment 7 Pavel Moravec 2015-01-16 07:46:27 UTC
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.

Comment 8 Petr Matousek 2015-03-25 15:47:28 UTC
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

Comment 9 Petr Matousek 2015-03-27 13:53:22 UTC
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.

Comment 10 Petr Matousek 2015-03-27 13:55:27 UTC
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}] } }"

Comment 11 Petr Matousek 2015-03-27 13:57:53 UTC
(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}] } }"

Comment 16 errata-xmlrpc 2015-04-14 13:46:04 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.

https://rhn.redhat.com/errata/RHEA-2015-0805.html


Note You need to log in before you can comment on or make changes to this bug.