rabbitmq-jms-client: createSubscriber() binds durable queues that persist until connection down

[al...@isomorphic.com]

RMQSession.createConsumerInternal()->declareRMQQueue() creates an exclusive:true queue which is then bound via this.channel.queueBind().  Looking at the comments in declareRMQQueue(), it appears the intent is to rely on the fact that the queue is exclusive for auto-removal from broker on connection down.  

My understanding from reading the JMS spec is that connections are fairly heavy-weight - this is why they're thread-safe objects - I think the intent is to generally have one Connection per JVM and then create a Session per thread and consumers/producers off those to transact messages.

But currently, if you do this, the broker builds up idle queues as JMS consumers are close()d and new ones instantiated.  This continues until the JMS Connection is close()d - but in my case this doesn't happen until the JVM is shut down.  

Is the current functionality basically to spec or?  Should I really be using one Connection per thread in my app?  My specific use case is a servlet container wherein the browser connects via HTTP to a Servlet to consume messages.  So I have the one JMS connection for the app server JVM and the servlet binds a session, creates a consumer, reads messages for a while, then cycles the connection.

Is there a different pattern perhaps that I could use or should I just cycle connections?  It feels like the RMQSession should call queueDelete() during internalClose() on all queues that it dynamically bound for message consumers on Topics.  What do you guys think?

The only other option I see is to generate UUIDs myself and call createDurableSubscriber() which then allows me to unsubscribe() (which does clean up the broker queue).  But this is sub-optimal because this type of durable subscriber is non-exclusive and persists even after my JVM is shut down.  I can write cleanup routines to do this, but an unclean shutdown would permanently leak broker queues, which is arguably worse.

[Arnaud Cogoluègnes]

Your understanding about JMS connection and session lifecycles makes sense and this is what we usually observe in the field.

The best option seems to track created queues and delete them on internalClose as you suggest, but only for non-durable subscribers.

You can fill in a new issue [1], link to this thread, and why not provide a PR  :-)

[1] https://github.com/rabbitmq/rabbitmq-jms-client/issues

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
To post to this group, send email to rabbitmq-users@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[al...@isomorphic.com]

Thanks for the quick response.  Didn't bother with filling out a new issue (but can do so if you'd like) and went straight to a fix a PR.  

[1] https://github.com/rabbitmq/rabbitmq-jms-client/issues

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.