Description of problem: The delete-on-close lifetime policy is not applied when the exchange is in use. Version-Release number of selected component (if applicable): qpid-cpp-*-0.22-33 How reproducible: 100% Steps to Reproduce: 1. declare an exchange using delete-on-close lifetime policy, do not close the link yet 2. create another consumer on that exchange, do not close the link yet (so that the exchange remain in-use when the link from 1. is closed) 3. close the link from 1. 4. list exchanges 5. the exchange declared in 1. was not removed even if the link that declared it is already closed Actual results: delete-on-close lifetime policy is not applied when the exchange is in use. Expected results: The exchange declared with delete-on-close policy is removed when the link that declared the exchange is closed. Additional info: # $cppapi/drain -t 5 --connection-options "{protocol:'amqp1.0'}" "test_ex;{create:always, node:{type: topic, properties:{lifetime-policy:delete-on-close}}}" & [1] 1898 [root ~/dtests/dtests]# $cppapi/drain -t 20 --connection-options "{protocol:'amqp1.0'}" test_ex & [2] 1901 [root ~/dtests/dtests]# [1]- Done $cppapi/drain -t 5 --connection-options "{protocol:'amqp1.0'}" "test_ex;{create:always, node:{type: topic, properties:{lifetime-policy:delete-on-close}}}" [root ~/dtests/dtests]# qpid-config exchanges Type Exchange Name Attributes ================================================== ... topic test_ex
(note to gsim: I am investigating this BZ now) (note to myself: check if spout / qpid-send does not lead to equivalent problem)
Cancelling the consumer that created exchange with delete-on-close policy is reflected in broker by deleting the auxiliary queue, and nothing else (see "missing" OutgoingFromExchange class). To fix this, there would have to be a mechanism how to "propagate" the information "check if we dont need to destroy this (autodelete) node when this link is closing" from the queue to the exchange - probably somewhere in OutgoingFromQueue::~OutgoingFromQueue or OutgoingFromQueue::detached. But that would need nontrivial change while this bug is rather about consistency completeness than about a real use case.. (easier fix for very similar use case with producer creating delete-on-close posted in bz1073796)