Hide Forgot
Created attachment 482294 [details] A hacked up version of the drain example in python-qpid Description of problem: Exclusive, auto-delete queues not freed up on delete. They are deleted only when a session is closed, not when the receiver is closed. This has been fixed by upstream commit 1075777. Version-Release number of selected component (if applicable): qpid-cpp-server-0.7.946106-28.el5 How reproducible: Always Steps to Reproduce: 1. Run attached reproducer: ./drain 'my.topic/foo; {create:always,delete:always,node:{type:queue,x-declare:{exclusive:True,auto-delete:True}}}' and wait for "the queue should be there" 2. 'qpid-config queues' should show the queue (my.topic) 3. Press <enter> to get "the queue should be gone now" 4. Run 'qpid-config queues' again Actual results: Queue my.topic is present Expected results: Queue my.topic should not be present Additional info:
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: The broker maintained two lists of exclusive queues for a session, one of which was incorrect and at connection scope. Deletion of queues prior to the session closing did not result in removal of all references to the queue, thus preventing the queue object from being freed. Consequence: Exclusive queues that were deleted 'early' would not actually be freed up and would still be reported by management tools. Fix: Altered broker to only maintain one list of exclusive queues, at session scope, and delete any reference in that list when a queue is deleted 'early'. Result: Deletion now frees the queue up and the management reports are accurate.
Created attachment 483751 [details] Test demonstarting how this bug can also cause cluster inconsistency Run the attached test against a single node, enter a queue name then while leaving that test running add a new node to the cluster. This results in the new cluster having the queue and having it bound to amq.fanout, whereas it is already deleted on the first node. You can then just qpid-send to the test queue (which shuts the first cluster down), or send to amq.fanout and then receive off the test queue on the second node.
This issue has been fixed Verified on RHEL4.9, RHEL5.6 and RHEL6.1, architectures: i386, x86_64 packages installed: python-qpid-0.10-1.el5 python-qpid-qmf-0.10-2.el5 qpid-cpp-client-0.10-3.el5 qpid-cpp-client-devel-0.10-3.el5 qpid-cpp-client-devel-docs-0.10-3.el5 qpid-cpp-client-ssl-0.10-3.el5 qpid-cpp-mrg-debuginfo-0.10-3.el5 qpid-cpp-server-0.10-3.el5 qpid-cpp-server-cluster-0.10-3.el5 qpid-cpp-server-devel-0.10-3.el5 qpid-cpp-server-ssl-0.10-3.el5 qpid-cpp-server-store-0.10-3.el5 qpid-cpp-server-xml-0.10-3.el5 qpid-java-client-0.10-2.el5 qpid-java-common-0.10-2.el5 qpid-java-example-0.10-2.el5 qpid-java-jca-0.10-2.el5 qpid-qmf-0.10-2.el5 qpid-qmf-devel-0.10-2.el5 qpid-tools-0.10-2.el5 -> VERIFIED
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2011-0890.html