Description of problem: I am not able to create binding using cpp client with the following address: "ex;{ create: always, node: { type: topic }, link: { x-bindings: [{ exchange: 'ex', queue: 'q', key: 'key' }]}}" Moreover, parsing error occurs when trying to create empty binding with the following address: "ex;{ create: always, node: { type: topic }, link: { x-bindings: [{ exchange: 'ex', queue: 'q', key: '' }]}}" Unmatched delimiter, character 107 of ex;{ create: always, node: { type: topic }, link: { x-bindings: [{ exchange: 'ex', queue: 'q', key: '' }]}} Binding creation with the exactly same address works well for other clients (java,py) in both the cases. This was seen on RHEL6.1 x86_64, MRG 2.0 installed (this issue is also valid for MRG 1.3 branch) Version-Release number of selected component (if applicable): qpid-cpp-client-devel-0.10-6.el6.x86_64 How reproducible: 100% Steps to Reproduce: reproduction scenario 1: 1. drain "ex;{create: always,node:{type: topic,x-declare:{type:topic}}}" 2. drain "q;{create: always,node:{type: queue}}" 3. drain "ex;{ create: always, node: { type: topic }, link: { x-bindings: [{ exchange: 'ex', queue: 'q', key: 'key' }]}}" 4. qpid-config -b exchanges 5. binding is not listed reproduction scenario 2: 1. drain "ex;{create: always,node:{type: topic,x-declare:{type:topic}}}" 2. drain "q;{create: always,node:{type: queue}}" 3. drain "ex;{ create: always, node: { type: topic }, link: { x-bindings: [{ exchange: 'ex', queue: 'q', key: '' }]}}" 4. parsing error is displayed Actual results: reproduction scenario 1: command ends with success (no error message appears, return code is equal to 0), but the binding is not created reproduction scenario 2: Error message regarding Unmatched delimiter is printed out, binding is not created Expected results: No error message appears and binding is successfully created in both the reproduction scenarios Additional info:
The parsing error when dealing with empty strings has been fixed on trunk (see QPID-3330). The issue on binding behaviour is that the c++ client will explicitly unbind any link bindings when the link ends (i.e. when the sender/receiver closes). If the x-bindings are in the node, they will be not be tied to the scope of the link. I believe this is the correct behaviour and that it is the python ad java clients that are incorrect in not unbinding when a link ends.
Confirmed with Rafi that it is in fcat the python client (and JMS client) that are wrong here. They should remove any bindings defined as part of the link when that link ends (i.e. sender/receiver closes). Assuming you agree, how about we modify this to track the empty string parsing issue only, and then create separate BZs for the python and JMS client fixes?
Gordon, Thanks for clarification. So If I catch it right the behaviour is as follows: If I want to create binding that remains present until removed on demand or the broker is restarted, I need to use the node section of the address string. i.e.: drain "ex;{ create: always, node: { type: topic, x-bindings: [{ exchange: 'ex', queue: 'q', key: 'key' }]}}" If I want to create binding that is removed when the sender/receiver closes, I need to use the link section of the address string. i.e.: drain "ex;{ create: always, node: { type: topic }, link: { x-bindings: [{ exchange: 'ex', queue: 'q', key: 'key' }]}}" am I right? The python and JMS behaves opposite way.. Agreed, I will create the python and JMS bugzillas and we will track this issue as the empty string parsing issue only. (after confirmation the question mentioned above.)
Correct.
The cpp client functionality is correct, only the parsing error mentioned in Comment 0 is valid for this BZ. JMS and python clients do not handle bindings operations properly, so separate bugzillas will be filled against them.
Thanks Petr! Fix for the specific parsing committed upstream as http://svn.apache.org/viewvc?view=rev&rev=1141910.
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
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: Using an address string with the c++ messaging API that has a map within it with an empty value for some key. Consequence: A parsing exception is thrown. Fix: The parser has been updated to correctly handle empty values for key-value pairs in maps. Result: Using such an address will no longer result in a parsing exception.
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