| Summary: | JMS client does not delete persistent queues from topic exchange | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Kim van der Riet <kim.vdriet> | ||||
| Component: | qpid-java | Assignee: | Rajith Attapattu <rattapat+nobody> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | MRG Quality Engineering <mrgqe-bugs> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | Development | CC: | gsim | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-03-07 16:44:37 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
This is due to auto-delete being false when durable is selected. I was hoping to resolve this issue when I make a proper fix for bz 614684 However due to the reasons mentioned in that bz it's a bit difficult atm to make this workable. Currently if a user wants durable topics they need to use JMS Durable Subscriptions which has an explicit unsubscribe method. So from a users pov this will not be an issue. As a temp solution I am going to make some changes to the tests. In order to ensure the tests don't leave queues behind, they will be deleted at the end of the test. |
Created attachment 479387 [details] Modified JMS test script from qpid/java/tools/bin/ If a persistent topic subscription is created, the broker will create a queue with a matching store. However, when the subscription is cancelled and consumer.close() is called, the persistent queue and its bindings remain on the broker. In addition, and any further activity on that topic (persistent or not) will eventually cause the store to fill up cause an enqueue threshold exception. Using a modified test in java/tools/bin/perftest.sh (the entire file is attached): # Test 8 Topic Durable run_testcase "Topic_Dura" \ "$SUB_BASE_OPTS -Daddress=amq.topic/topic;{create:always,link:{durable:true}} $DURABLE -DtransDest=transientTopic" \ "$PUB_BASE_OPTS -Daddress=amq.topic/topic;{create:always,link:{durable:true}} $DURABLE -Dmsg_count=$MSG_COUNT -Dmsg_size=$SMALL_MSG_SIZE -DtransDest=transientTopic" # Test 10 Topic Durable 3 subs run_testcase "Topic_Dura_3_subs" \ "$SUB_BASE_OPTS -Daddress=amq.topic/topic;{create:always,link:{durable:true}} $DURABLE -DtransDest=transientTopic" \ "$PUB_BASE_OPTS -Daddress=amq.topic/topic;{create:always,link:{durable:true}} $DURABLE -Dmsg_count=$MSG_COUNT -Dmsg_size=$SMALL_MSG_SIZE -DtransDest=transientTopic" \ 3 Once this test has completed, running the following shows that the persistent queues created as part of these tests remain: [kpvdr@mrg42 ~]$ qpid-config queues Queue Name Attributes ====================================================================== TempQueue70b48148-e0e5-4358-a10b-535e7d23002c --durable excl TempQueue88bd0758-27ba-4cc9-9d6d-b2cb4eb4282a --durable excl TempQueue98415192-0ecb-4f06-92ee-8e2f2ee400ee --durable excl TempQueueccbef9c8-15c3-4684-bc87-ab0380b31959 --durable excl qmfc-v2-hb-mrg42.lab.bos.redhat.com.24751.1 auto-del excl --limit-policy=ring qmfc-v2-mrg42.lab.bos.redhat.com.24751.1 auto-del excl qmfc-v2-ui-mrg42.lab.bos.redhat.com.24751.1 auto-del excl --limit-policy=ring reply-mrg42.lab.bos.redhat.com.24751.1 auto-del excl topic-mrg42.lab.bos.redhat.com.24751.1 auto-del excl --limit-policy=ring [kpvdr@mrg42 ~]$ qpid-config exchanges -b amq.topic Exchange 'amq.topic' (topic) bind [topic] => TempQueue70b48148-e0e5-4358-a10b-535e7d23002c bind [topic] => TempQueue88bd0758-27ba-4cc9-9d6d-b2cb4eb4282a bind [topic] => TempQueue98415192-0ecb-4f06-92ee-8e2f2ee400ee bind [topic] => TempQueueccbef9c8-15c3-4684-bc87-ab0380b31959 [kpvdr@mrg42 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =============================================================================================================================== TempQueueccbef9c8-15c3-4684-bc87-ab0380b31959 Y Y 202k 303k 101k 12.9m 19.4m 6.46m 0 2 TempQueue88bd0758-27ba-4cc9-9d6d-b2cb4eb4282a Y Y 0 101k 101k 0 6.46m 6.46m 0 2 qmfc-v2-hb-mrg42.lab.bos.redhat.com.24786.1 Y Y 0 0 0 0 0 0 1 2 topic-mrg42.lab.bos.redhat.com.24786.1 Y Y 0 0 0 0 0 0 1 4 reply-mrg42.lab.bos.redhat.com.24786.1 Y Y 0 71 71 0 30.3k 30.3k 1 2 TempQueue98415192-0ecb-4f06-92ee-8e2f2ee400ee Y Y 0 101k 101k 0 6.46m 6.46m 0 2 TempQueue70b48148-e0e5-4358-a10b-535e7d23002c Y Y 0 101k 101k 0 6.46m 6.46m 0 2 qmfc-v2-mrg42.lab.bos.redhat.com.24786.1 Y Y 0 11 11 0 8.15k 8.15k 1 2 qmfc-v2-ui-mrg42.lab.bos.redhat.com.24786.1 Y Y 0 0 0 0 0 0 1 1 This last check shows that the queue TempQueueccbef9c8-15c3-4684-bc87-ab0380b31959 has accumulated 202k messages from the second test, even though it does not have an active subscriber. This store will eventually overflow.