Description of problem: When the if_empty=true and if_unused=true flags are passed to the deleteObject method on the c++ broker, the queue is deleted even if it is not empty or in use. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. qpid-config add queue q 2. spout -c 1 q 3. qpid-config del queue q Actual results: The queue is deleted. Expected results: Failed: Exception: Exception from Agent: {u'error_code': 7, u'error_text': 'precondition-failed: Cannot delete queue q; queue not empty (qpid/broker/Broker.cpp:911)'} Additional info: The latest release has a workaround implemented in qpid-config. This fix should remove that workaround and fix the C++ broker instead.
I suppose that fix for this issue won't affect the addressing behaviour, ie: Following command will still create the queue q, send ten messages on that queue and finally remove the (non-empty) queue. Are my assumptions correct? # ./spout -c 10 "q;{create:sender. delete:sender}"
That is correct. ./spout -c 10 "q;{create:sender, delete:sender}" will not generate an exception and the queue will be deleted. The exception can only be raised when the if_empty or if_unused flags are used.
Created attachment 702380 [details] Add checkDeleteQueue method to broker Patch reviewed
Fix committed upstream at revision 1456081.
Tested on RHEL6.4 (both i386 and x86_64). This issue has been fixed. Packages used for testing: python-qpid-0.22-4.el6 python-qpid-qmf-0.22-8.el6 qpid-cpp-client-0.22-10.el6 qpid-cpp-client-devel-0.22-10.el6 qpid-cpp-client-devel-docs-0.22-10.el6 qpid-cpp-client-ssl-0.22-10.el6 qpid-cpp-server-0.22-10.el6 qpid-cpp-server-devel-0.22-10.el6 qpid-cpp-server-ssl-0.22-10.el6 qpid-cpp-server-store-0.22-10.el6 qpid-cpp-server-xml-0.22-10.el6 qpid-java-client-0.22-5.el6 qpid-java-common-0.22-5.el6 qpid-java-example-0.22-5.el6 qpid-jca-0.18-8.el6 qpid-jca-xarecovery-0.18-8.el6 qpid-proton-c-0.4-2.2.el6 qpid-qmf-0.22-8.el6 qpid-snmpd-1.0.0-12.el6 qpid-tools-0.22-3.el6 rh-qpid-cpp-tests-0.22-10.el6 -> VERIFIED
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/RHEA-2014-1296.html