The expected behavior of a topic consumer is to persist the subscription queue when the topic consumer is closed. The subscription queue is deleted automatically when the session is closed due to being marked auto-delete. It was discovered that the subscription queue remained on the broker, even after the subscription queue was closed. The fix now ensures the subscription queue is deleted when the consumer is closed, with the exception of JMS durable subscriptions.
Created attachment 718037[details]
Reproducer
Description of problem:
Having a topic consumer, closing it should delete its auxiliary auto-delete exclusive queue. Currently Java client does so even when the session is closed, while the session can be used to subsequent producer traffic, e.g.
Version-Release number of selected component (if applicable):
qpid-java-*-0.18-7
How reproducible:
100%
Steps to Reproduce:
1. java test_00808098 "amq.topic/key3; { node:{ type:topic}, link:{x-bindings:[{ exchange:'amq.topic', key:'key1'}, { exchange:'amq.topic', key:'key2' }]}}"
Consumer created, press enter to continue
(in another terminal, run "qpid-config queues -r" to see the aux.queue named like TempQueuef6f5a3f6-6498-49c2-ac98-92ae73bff2b4)
Consumer closed, press enter to continue
(in the second terminal, run "qpid-config queues -r" again and check if the queue exists or not)
Session closed, press enter to continue
(in the second terminal, run "qpid-config queues -r" again and check if the queue exists or not)
Connection closed, press enter to continue
Actual results:
The first check after consumer closed shows the queue present. The queue is deleted even after session is closed (i.e. second check).
Expected results:
Even the first check shows the queue already gone.
Additional info:
This would align JMS client behavior with C++ and Python client behavior.
Also it would prevent another bug - see that after consumer is closed, binding amq.topic -> key3 -. aux.queue also exists (key3 is the routing key from the address string).
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.
https://rhn.redhat.com/errata/RHEA-2015-0805.html
Created attachment 718037 [details] Reproducer Description of problem: Having a topic consumer, closing it should delete its auxiliary auto-delete exclusive queue. Currently Java client does so even when the session is closed, while the session can be used to subsequent producer traffic, e.g. Version-Release number of selected component (if applicable): qpid-java-*-0.18-7 How reproducible: 100% Steps to Reproduce: 1. java test_00808098 "amq.topic/key3; { node:{ type:topic}, link:{x-bindings:[{ exchange:'amq.topic', key:'key1'}, { exchange:'amq.topic', key:'key2' }]}}" Consumer created, press enter to continue (in another terminal, run "qpid-config queues -r" to see the aux.queue named like TempQueuef6f5a3f6-6498-49c2-ac98-92ae73bff2b4) Consumer closed, press enter to continue (in the second terminal, run "qpid-config queues -r" again and check if the queue exists or not) Session closed, press enter to continue (in the second terminal, run "qpid-config queues -r" again and check if the queue exists or not) Connection closed, press enter to continue Actual results: The first check after consumer closed shows the queue present. The queue is deleted even after session is closed (i.e. second check). Expected results: Even the first check shows the queue already gone. Additional info: This would align JMS client behavior with C++ and Python client behavior. Also it would prevent another bug - see that after consumer is closed, binding amq.topic -> key3 -. aux.queue also exists (key3 is the routing key from the address string).