Description of problem: If MDB is used with topic and deployed, on the qpid side queues are created with name consisting of name of topic defined in EAP and pseudorandom (probably UUID) string. After undeploying the MDB connections are closed, nothing is connected to that queues on qpid side, but these remains there, if the MDB is deployed once again, new queues on qpid side are created and if the message is send to the JMS topic, it's delivered to all queues on qpid side, even to these that are not attached to any running mdb. This behavior can lead to qpid server full of thousands of unused queues full of messages, which won't be read anymore. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. donwload and unzip eap-5.1.1 2. deploy mrg jca resource adapter and a jms topic (as a admin object) 3. deploy MDB bind to that topic and using mrg jca adapter. repeat [ 4. undeploy mdb - deploy mdb ] for n times 5. send a message or two to that jms topic Actual results: on server, where qpidd is installed, you can see after running qpid-stat -q lots of queues with non-processed messages and just few with processed ones (these are used with currently deployed MDB). Expected results: AFAIK, there should not remain queues on qpid side, because this could lead to big resource leak (memory, diskspace, cpu). Additional info:
Please provide your *-ds.xml file showing the creation of the AdminObject.
jiri, You can use qpid-tool to look at the queues in question. 1) Are these queues marked auto-delete ? 2) Do you see any consumers on these queues ? These questions will give some clues about, a) If the queues are not marked auto-delete then they will not be deleted when the connection is closed. b) If the connection that creates the queue is still around then the broker will not delete the queue. Regards, Rajith
Weston, You can use *-ds.xml from qpid-java-jca examples, just configure the build.xml to use correct eap server and profile and mrg url and modify QpidListener.java to use topic/Hello.
Rajith, after first deployment of MDB consumers are connected [jsedlace@mrg01 ~]$ qpid-stat -q; qpid-config queues Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== _@_54fb2c64-4837-4988-bca9-0ed88e76b03c 0 0 0 0 0 0 1 2 _@_08dabeb3-f6d9-452c-9c82-ed6f58481896 0 0 0 0 0 0 1 2 _@_a4993cd0-6dbf-4b3b-833e-ce0ebc8e82bb 0 0 0 0 0 0 1 2 topic-mrg01.mw.lab.eng.bos.redhat.com.7212.1 Y Y 0 0 0 0 0 0 1 4 _@_4bbe307d-50cb-41d2-85a5-d1c079786c16 0 0 0 0 0 0 1 2 _@_90dd93f2-00f8-4e9a-81dc-8cbec67d348d 0 0 0 0 0 0 1 2 qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 10 10 0 170 170 1 4 qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7212.1 Y Y 0 0 0 0 0 0 1 1 _@_b93ba346-8f78-472f-a9ab-4b0cbe3b54f3 0 0 0 0 0 0 1 2 _@_c048fd2b-0818-4059-add0-dfec015825a4 0 0 0 0 0 0 1 2 _@_0188fc8a-bd0e-4dc3-a26d-2ce9ff88afbc 0 0 0 0 0 0 1 2 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7212.1 Y Y 0 0 0 0 0 0 1 2 reply-mrg01.mw.lab.eng.bos.redhat.com.7212.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 _@_0e1896da-1a39-4315-a9a1-db01afd3cb9e 0 0 0 0 0 0 1 2 _@_f20202b7-6fc9-4b14-9bc5-08908ff38e35 0 0 0 0 0 0 1 2 _@_cb965a81-1bdc-4134-b0e7-5145452d06d8 0 0 0 0 0 0 1 2 _@_9545c392-e3cb-4d61-a9b5-7ee72977e33b 0 0 0 0 0 0 1 2 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7212.1 Y Y 0 13 13 0 97.7k 97.7k 1 2 _@_889e14ab-7e70-4f6e-b4b2-e203e270afa8 0 0 0 0 0 0 1 2 _@_93904b7a-f6ec-4266-8b5c-cf28e7a1f10c 0 0 0 0 0 0 1 2 _@_72cbc5e9-0c75-46a2-9a2f-bc1b20202950 0 0 0 0 0 0 1 2 after first undeployment consumers are disconnected: [jsedlace@mrg01 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== _@_54fb2c64-4837-4988-bca9-0ed88e76b03c 0 0 0 0 0 0 0 2 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7258.1 Y Y 0 13 13 0 75.4k 75.4k 1 2 _@_a4993cd0-6dbf-4b3b-833e-ce0ebc8e82bb 0 0 0 0 0 0 0 2 _@_4bbe307d-50cb-41d2-85a5-d1c079786c16 0 0 0 0 0 0 0 2 _@_90dd93f2-00f8-4e9a-81dc-8cbec67d348d 0 0 0 0 0 0 0 2 qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 18 18 0 306 306 1 4 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7258.1 Y Y 0 0 0 0 0 0 1 2 _@_b93ba346-8f78-472f-a9ab-4b0cbe3b54f3 0 0 0 0 0 0 0 2 _@_c048fd2b-0818-4059-add0-dfec015825a4 0 0 0 0 0 0 0 2 _@_0188fc8a-bd0e-4dc3-a26d-2ce9ff88afbc 0 0 0 0 0 0 0 2 _@_0e1896da-1a39-4315-a9a1-db01afd3cb9e 0 0 0 0 0 0 0 2 _@_f20202b7-6fc9-4b14-9bc5-08908ff38e35 0 0 0 0 0 0 0 2 qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7258.1 Y Y 0 0 0 0 0 0 1 1 _@_cb965a81-1bdc-4134-b0e7-5145452d06d8 0 0 0 0 0 0 0 2 topic-mrg01.mw.lab.eng.bos.redhat.com.7258.1 Y Y 0 0 0 0 0 0 1 4 reply-mrg01.mw.lab.eng.bos.redhat.com.7258.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 _@_9545c392-e3cb-4d61-a9b5-7ee72977e33b 0 0 0 0 0 0 0 2 _@_889e14ab-7e70-4f6e-b4b2-e203e270afa8 0 0 0 0 0 0 0 2 _@_08dabeb3-f6d9-452c-9c82-ed6f58481896 0 0 0 0 0 0 0 2 _@_93904b7a-f6ec-4266-8b5c-cf28e7a1f10c 0 0 0 0 0 0 0 2 _@_72cbc5e9-0c75-46a2-9a2f-bc1b20202950 0 0 0 0 0 0 0 2 after second deployment consumers are connected to freshly created queues, old ones remains there and probably wont be used anymore: [jsedlace@mrg01 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== _@_cb965a81-1bdc-4134-b0e7-5145452d06d8 0 0 0 0 0 0 0 2 _@_54fb2c64-4837-4988-bca9-0ed88e76b03c 0 0 0 0 0 0 0 2 _@_dd894f1a-a4e4-45a2-81e0-ce5ab79fcedf 0 0 0 0 0 0 1 2 _@_e2b2ca27-0816-4cbe-9068-71faf79f814d 0 0 0 0 0 0 1 2 _@_5321e635-d8d5-4f2f-8742-7835fb200f44 0 0 0 0 0 0 1 2 _@_2a8b55ae-1f43-47da-9b42-d99826785604 0 0 0 0 0 0 1 2 _@_08dabeb3-f6d9-452c-9c82-ed6f58481896 0 0 0 0 0 0 0 2 _@_9c3b6345-2431-4091-8b53-5f25281364bd 0 0 0 0 0 0 1 2 _@_a4993cd0-6dbf-4b3b-833e-ce0ebc8e82bb 0 0 0 0 0 0 0 2 _@_4bbe307d-50cb-41d2-85a5-d1c079786c16 0 0 0 0 0 0 0 2 _@_2a714560-1093-4e08-b604-2475dc3e5834 0 0 0 0 0 0 1 2 qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 22 22 0 374 374 1 4 _@_7f86ba7b-44b4-4be1-a9b0-4222e24e01f5 0 0 0 0 0 0 1 2 _@_b93ba346-8f78-472f-a9ab-4b0cbe3b54f3 0 0 0 0 0 0 0 2 _@_fadbe3aa-7f2d-431d-9274-b2744a8619c0 0 0 0 0 0 0 1 2 _@_c048fd2b-0818-4059-add0-dfec015825a4 0 0 0 0 0 0 0 2 _@_0188fc8a-bd0e-4dc3-a26d-2ce9ff88afbc 0 0 0 0 0 0 0 2 _@_1aff0a70-7ae9-4500-9669-5b26e1b99c46 0 0 0 0 0 0 1 2 topic-mrg01.mw.lab.eng.bos.redhat.com.7282.1 Y Y 0 0 0 0 0 0 1 4 _@_86f05a0c-625d-43c4-918c-b063e2013769 0 0 0 0 0 0 1 2 _@_12d9de91-a7e9-4f7b-a15a-fb81860ff6c0 0 0 0 0 0 0 1 2 _@_0e1896da-1a39-4315-a9a1-db01afd3cb9e 0 0 0 0 0 0 0 2 _@_f20202b7-6fc9-4b14-9bc5-08908ff38e35 0 0 0 0 0 0 0 2 _@_90dd93f2-00f8-4e9a-81dc-8cbec67d348d 0 0 0 0 0 0 0 2 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7282.1 Y Y 0 0 0 0 0 0 1 2 _@_6401aaab-5b1b-4865-b487-e4780435b8ff 0 0 0 0 0 0 1 2 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7282.1 Y Y 0 13 13 0 98.5k 98.5k 1 2 qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7282.1 Y Y 0 0 0 0 0 0 1 1 _@_9545c392-e3cb-4d61-a9b5-7ee72977e33b 0 0 0 0 0 0 0 2 _@_14ac87df-c487-4b70-8e4f-7ac01731f141 0 0 0 0 0 0 1 2 _@_3aa689d9-5d0c-40bb-b72a-00425bf342cb 0 0 0 0 0 0 1 2 reply-mrg01.mw.lab.eng.bos.redhat.com.7282.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 _@_889e14ab-7e70-4f6e-b4b2-e203e270afa8 0 0 0 0 0 0 0 2 _@_93904b7a-f6ec-4266-8b5c-cf28e7a1f10c 0 0 0 0 0 0 0 2 _@_4ab979b2-6313-4581-92ef-570ea7de83c2 0 0 0 0 0 0 1 2 _@_72cbc5e9-0c75-46a2-9a2f-bc1b20202950 0 0 0 0 0 0 0 2 after one message send to the topic, connected consumers received, message remains in queues without consumers and remains there probably forever: [jsedlace@mrg01 ~]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind =================================================================================================================================== _@_cb965a81-1bdc-4134-b0e7-5145452d06d8 1 1 0 40 40 0 0 2 _@_54fb2c64-4837-4988-bca9-0ed88e76b03c 1 1 0 40 40 0 0 2 _@_dd894f1a-a4e4-45a2-81e0-ce5ab79fcedf 0 1 1 0 40 40 1 2 _@_e2b2ca27-0816-4cbe-9068-71faf79f814d 0 1 1 0 40 40 1 2 _@_5321e635-d8d5-4f2f-8742-7835fb200f44 0 1 1 0 40 40 1 2 _@_2a8b55ae-1f43-47da-9b42-d99826785604 0 1 1 0 40 40 1 2 _@_08dabeb3-f6d9-452c-9c82-ed6f58481896 1 1 0 40 40 0 0 2 _@_9c3b6345-2431-4091-8b53-5f25281364bd 0 1 1 0 40 40 1 2 qmfc-v2-ui-mrg01.mw.lab.eng.bos.redhat.com.7298.1 Y Y 0 0 0 0 0 0 1 1 qmfc-v2-hb-mrg01.mw.lab.eng.bos.redhat.com.7298.1 Y Y 0 2 2 0 481 481 1 2 _@_a4993cd0-6dbf-4b3b-833e-ce0ebc8e82bb 1 1 0 40 40 0 0 2 qmfc-v2-mrg01.mw.lab.eng.bos.redhat.com.7298.1 Y Y 0 13 13 0 100k 100k 1 2 _@_4bbe307d-50cb-41d2-85a5-d1c079786c16 1 1 0 40 40 0 0 2 _@_2a714560-1093-4e08-b604-2475dc3e5834 0 1 1 0 40 40 1 2 qmfagent-8be82412-a20a-471f-86b0-728fdcb37cda Y Y 0 24 24 0 408 408 1 4 _@_7f86ba7b-44b4-4be1-a9b0-4222e24e01f5 0 1 1 0 40 40 1 2 topic-mrg01.mw.lab.eng.bos.redhat.com.7298.1 Y Y 0 0 0 0 0 0 1 4 _@_b93ba346-8f78-472f-a9ab-4b0cbe3b54f3 1 1 0 40 40 0 0 2 _@_fadbe3aa-7f2d-431d-9274-b2744a8619c0 0 1 1 0 40 40 1 2 _@_c048fd2b-0818-4059-add0-dfec015825a4 1 1 0 40 40 0 0 2 _@_0188fc8a-bd0e-4dc3-a26d-2ce9ff88afbc 1 1 0 40 40 0 0 2 _@_1aff0a70-7ae9-4500-9669-5b26e1b99c46 0 1 1 0 40 40 1 2 reply-mrg01.mw.lab.eng.bos.redhat.com.7298.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 _@_86f05a0c-625d-43c4-918c-b063e2013769 0 1 1 0 40 40 1 2 _@_12d9de91-a7e9-4f7b-a15a-fb81860ff6c0 0 1 1 0 40 40 1 2 _@_0e1896da-1a39-4315-a9a1-db01afd3cb9e 1 1 0 40 40 0 0 2 _@_f20202b7-6fc9-4b14-9bc5-08908ff38e35 1 1 0 40 40 0 0 2 _@_90dd93f2-00f8-4e9a-81dc-8cbec67d348d 1 1 0 40 40 0 0 2 _@_6401aaab-5b1b-4865-b487-e4780435b8ff 0 1 1 0 40 40 1 2 _@_9545c392-e3cb-4d61-a9b5-7ee72977e33b 1 1 0 40 40 0 0 2 _@_14ac87df-c487-4b70-8e4f-7ac01731f141 0 1 1 0 40 40 1 2 _@_3aa689d9-5d0c-40bb-b72a-00425bf342cb 0 1 1 0 40 40 1 2 _@_889e14ab-7e70-4f6e-b4b2-e203e270afa8 1 1 0 40 40 0 0 2 _@_93904b7a-f6ec-4266-8b5c-cf28e7a1f10c 1 1 0 40 40 0 0 2 _@_4ab979b2-6313-4581-92ef-570ea7de83c2 0 1 1 0 40 40 1 2 _@_72cbc5e9-0c75-46a2-9a2f-bc1b20202950 1 1 0 40 40 0 0 2 This output was done with default examples from qpid-java-jca package. This cannot be the default behavior, it can lead into memory leaks. The adapter should probably configure the topic to be auto deleted if nothing special is set.
In looking at this, we may be missing a syntax option from the BURL side of things: Please try creating a simple Topic/Queue admin object(s) with the following syntax (note, a Queue will probably be easier since you most likely have a ton of old topics around): destinationAddress=direct://amq.direct//hello.Queue?autodelete='true' or destinationAddress=BURL:topic://amq.topic//hello.Topic?routingKey='hello.Topic',autodelete='true' I want to take the simplest case because I believe this is an issue with syntax. I have run a simple tests and it shows to be working so I want to eliminate any differences we may have between our configurations.
Example: [wmprice@mrgm1 qpid-java-jca]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind ========================================================================================================= qmfc-v2-hb-mrgm1.17263.1 Y Y 0 0 0 0 0 0 1 2 topic-mrgm1.17263.1 Y Y 0 0 0 0 0 0 1 4 qmfc-v2-mrgm1.17263.1 Y Y 0 11 11 0 8.11k 8.11k 1 2 reply-mrgm1.17263.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 qmfc-v2-ui-mrgm1.17263.1 Y Y 0 0 0 0 0 0 1 1 client_id:hello.topic Y 13 13 0 173 173 0 0 2 <mbean code="org.jboss.resource.deployment.AdminObject" name="qpid.jca:name=HelloQueue"> <attribute name="JNDIName">HelloQueue</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends> <attribute name="Type">javax.jms.Destination</attribute> <attribute name="Properties"> destinationType=QUEUE <!--note if you require the older BURL syntax, uncomment the line below and comment the ADDR syntax line> destinationAddress=BURL:direct://amq.direct//hello.Queue destinationAddress=hello.Queue;{create:always, node:{type:queue, x-declare:{auto-delete:true}}} --> destinationAddress=direct://amq.direct//hello.Queue?autodelete='true' </attribute> </mbean> <mbean code="org.jboss.resource.deployment.AdminObject" name="qpid.jca:name=GoodByeQueue"> <attribute name="JNDIName">GoodByeQueue</attribute> <depends optional-attribute-name="RARName">jboss.jca:service=RARDeployment,name='qpid-ra-0.10.rar'</depends> <attribute name="Type">javax.jms.Destination</attribute> <attribute name="Properties"> destinationType=QUEUE <!--note if you require the older BURL syntax, uncomment the line below and comment the ADDR syntax line> destinationAddress=goodbye.Queue;{create:always, node:{type:queue, x-declare:{auto-delete:true}}} --> destinationAddress=direct://amq.direct//goodbye.Queue </attribute> </mbean> Note, the Goodbye Queue is not flagged as auto delete Start EAP: 14:19:42,823 INFO [AdminObject] Bound admin object 'org.apache.qpid.ra.admin.QpidDestinationProxy' at 'HelloQueue' 14:19:42,830 INFO [AdminObject] Bound admin object 'org.apache.qpid.ra.admin.QpidDestinationProxy' at 'GoodByeQueue' [wmprice@mrgm1 qpid-java-jca]$ qpid-stat -q Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind ================================================================================================================================= qmfc-v2-mrgm1.17287.1 Y Y 0 11 11 0 63.8k 63.8k 1 2 _ Y Y 0 0 0 0 0 0 1 2 topic-mrgm1.17287.1 Y Y 0 0 0 0 0 0 1 4 _ Y Y 0 0 0 0 0 0 1 2 client_id:hello.topic Y 13 13 0 173 173 0 0 2 _ Y Y 0 0 0 0 0 0 1 2 _ Y Y 0 0 0 0 0 0 1 2 _ Y Y 0 0 0 0 0 0 1 2 hello.Queue Y 0 0 0 0 0 0 15 2 _ Y Y 0 0 0 0 0 0 1 2 qmfc-v2-hb-mrgm1.17287.1 Y Y 0 0 0 0 0 0 1 2 reply-mrgm1.17287.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 _ Y Y 0 0 0 0 0 0 1 2 _ Y Y 0 0 0 0 0 0 1 2 goodbye.Queue 0 0 0 0 0 0 10 2 _ Y Y 0 0 0 0 0 0 1 2 _ Y Y 0 0 0 0 0 0 1 2 qmfc-v2-ui-mrgm1.17287.1 Kind of hard to read but hello.Queue is auto delete, goodbye.Queue is not. Also, note the topic subscribers are auto delete. Shut down EAP Queues queue dur autoDel excl msg msgIn msgOut bytes bytesIn bytesOut cons bind ========================================================================================================= qmfc-v2-hb-mrgm1.17310.1 Y Y 0 0 0 0 0 0 1 2 reply-mrgm1.17310.1 Y Y 0 58 58 0 22.2k 22.2k 1 2 qmfc-v2-mrgm1.17310.1 Y Y 0 11 11 0 8.11k 8.11k 1 2 qmfc-v2-ui-mrgm1.17310.1 Y Y 0 0 0 0 0 0 1 1 goodbye.Queue 0 0 0 0 0 0 0 2 topic-mrgm1.17310.1 Y Y 0 0 0 0 0 0 1 4 client_id:hello.topic Y 13 13 0 173 173 0 0 2 goodbye.Queue remains, helloQueue does not.
Note, all the temporary queues for topics have been removed as well.
So, if I understand it well, defining topics with autodelete=true will let them disappear after disconnecting, but only if no message is waiting for the delivery for that particular temporary topic. Is it good habit to set autodelete=true also for jms queues?
Correct. That is if you want them to be removed when you un-deploy your application.
Thanks for answers, closing.