Bug 786555

Summary: qpid-config add queue <existing_queue_name> returns success.
Product: Red Hat Enterprise MRG Reporter: Leonid Zhaldybin <lzhaldyb>
Component: qpid-toolsAssignee: Ernie <eallen>
Status: CLOSED ERRATA QA Contact: Leonid Zhaldybin <lzhaldyb>
Severity: high Docs Contact:
Priority: medium    
Version: 2.1CC: esammons, iboverma, jross, mcressma, tross
Target Milestone: 2.3   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-tools-0.18-1 Doc Type: Bug Fix
Doc Text:
Cause: Use qpid-config to create a queue or exchange with the same name but different options as an existing queue or exchange Consequence: The command succeeds but the options are not changed for the existing queue or exchange Fix: A different library was used. This new library returns and error when an attempt is made to create an existing queue or exchange Result: An error is returned when attempting to create a queue or exchange name that already exists
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-06 18:55:01 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:

Description Leonid Zhaldybin 2012-02-01 18:31:11 UTC
Description of problem:
If a user tries to create a queue or an exchange with the name identical to the one of already existing entity, the command returns success, and the existing queue or exchange remains unchanged:

[root@lzhaldyb-rhel62x ~]# qpid-config queues | grep test_queue
[root@lzhaldyb-rhel62x ~]# qpid-config add queue test_queue --max-queue-size=10 --limit-policy=reject --flow-stop-count=0 --flow-resume-count=0
[root@lzhaldyb-rhel62x ~]# qpid-config queues | grep test_queue
test_queue                           --max-queue-size=10 --limit-policy=reject --flow-stop-count=0 --flow-resume-count=0 --argument qpid.flow_resume_count=0
[root@lzhaldyb-rhel62x ~]# qpid-config add queue test_queue --max-queue-size=123 --limit-policy=ring --durable
[root@lzhaldyb-rhel62x ~]# echo $?
0
[root@lzhaldyb-rhel62x ~]# qpid-config queues | grep test_queue
test_queue                           --max-queue-size=10 --limit-policy=reject --flow-stop-count=0 --flow-resume-count=0 --argument qpid.flow_resume_count=0

Version-Release number of selected component (if applicable):
python-qpid-0.14-1.el6.noarch
python-qpid-qmf-0.14-3.el6.x86_64
qpid-cpp-client-0.14-1.el6.x86_64
qpid-cpp-client-devel-0.14-1.el6.x86_64
qpid-cpp-client-devel-docs-0.12-6.el6.noarch
qpid-cpp-server-0.14-1.el6.x86_64
qpid-cpp-server-devel-0.14-1.el6.x86_64
qpid-cpp-server-store-0.14-1.el6.x86_64
qpid-cpp-server-xml-0.14-1.el6.x86_64
qpid-java-client-0.14-1.el6.noarch
qpid-java-common-0.14-1.el6.noarch
qpid-java-example-0.14-1.el6.noarch
qpid-qmf-0.14-3.el6.x86_64
qpid-tools-0.14-1.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. Create a queue or an exchange on broker.
2. Try to create it again with different parameters.
  
Actual results:
The command returns success, even if the parameters of the second command are different from those of the first one. The already existing entity left unchanged.

Expected results:
If entity with the same name but different parameters already exists, the command should return an error.

Additional info:

Comment 1 Ted Ross 2012-04-23 18:05:46 UTC
This is fixed in Qpid 0.16.

See issue: https://issues.apache.org/jira/browse/QPID-3851

In transitioning to the higher-performance access library, the "declare" behavior was replaced by a "create" semantic that fails when an already-existing object has the same name.

Comment 3 Leonid Zhaldybin 2012-10-08 10:54:17 UTC
Tested on RHEL5.8 and RHEL6.3 (both i386 and x86_64). The qpid-config tool returns an error ('object already exists') if a queue or an exchange exists already on a broker.

Packages used for testing:

RHEL5.8:
python-qpid-0.18-1.el5
python-qpid-qmf-0.18-1.el5
qpid-cpp-client-0.18-1.el5
qpid-cpp-client-devel-0.18-1.el5
qpid-cpp-client-devel-docs-0.18-1.el5
qpid-cpp-client-ssl-0.18-1.el5
qpid-cpp-server-0.18-1.el5
qpid-cpp-server-cluster-0.18-1.el5
qpid-cpp-server-devel-0.18-1.el5
qpid-cpp-server-ssl-0.18-1.el5
qpid-cpp-server-store-0.18-1.el5
qpid-cpp-server-xml-0.18-1.el5
qpid-java-client-0.18-2.el5
qpid-java-common-0.18-2.el5
qpid-java-example-0.18-2.el5
qpid-jca-0.18-2.el5
qpid-jca-xarecovery-0.18-2.el5
qpid-qmf-0.18-1.el5
qpid-qmf-devel-0.18-1.el5
qpid-tools-0.18-1.el5

RHEL6.3:
python-qpid-0.18-1.el6_3
python-qpid-qmf-0.18-1.el6_3
qpid-cpp-client-0.18-1.el6_3
qpid-cpp-client-devel-0.18-1.el6_3
qpid-cpp-client-devel-docs-0.18-1.el6_3
qpid-cpp-server-0.18-1.el6_3
qpid-cpp-server-cluster-0.18-1.el6_3
qpid-cpp-server-devel-0.18-1.el6_3
qpid-cpp-server-store-0.18-1.el6_3
qpid-cpp-server-xml-0.18-1.el6_3
qpid-java-client-0.18-2.el6
qpid-java-common-0.18-2.el6
qpid-java-example-0.18-2.el6
qpid-qmf-0.18-1.el6_3
qpid-tools-0.18-1.el6_3

-> VERIFIED

Comment 5 errata-xmlrpc 2013-03-06 18:55:01 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-2013-0561.html