Bug 682218

Summary: exclusive, auto-delete queues not freed up in the broker on queue delete
Product: Red Hat Enterprise MRG Reporter: Siddhesh Poyarekar <spoyarek>
Component: qpid-cppAssignee: Gordon Sim <gsim>
Status: CLOSED ERRATA QA Contact: Petr Matousek <pematous>
Severity: medium Docs Contact:
Priority: high    
Version: 1.3CC: freznice, gsim, mcressma, mnewsome, pematous
Target Milestone: 2.0   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: qpid-cpp-mrg-0.9.1079953-1 Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
: 716247 (view as bug list) Environment:
Last Closed: 2011-06-23 15:45:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 716247, 723959    
Attachments:
Description Flags
A hacked up version of the drain example in python-qpid
none
Test demonstarting how this bug can also cause cluster inconsistency none

Description Siddhesh Poyarekar 2011-03-04 13:55:09 UTC
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:

Comment 2 Gordon Sim 2011-03-07 12:28:52 UTC
    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.

Comment 3 Gordon Sim 2011-03-11 15:21:56 UTC
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.

Comment 4 Petr Matousek 2011-04-15 14:43:29 UTC
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

Comment 5 errata-xmlrpc 2011-06-23 15:45:14 UTC
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