<div dir="ltr"><div>We use consumers here with the spring libraries.  If you use them, there's a "Shutdown" command you can call as needed.  We've had pretty good luck with it so far.  The spring consumer stuff manages how many consumers are running, connection threading, etc. - and it has very good shutdown hooks.<br>
</div>Jason<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 2, 2014 at 3:02 PM, Bertrand Guay-Paquet <span dir="ltr"><<a href="mailto:bernie@step.polymtl.ca" target="_blank">bernie@step.polymtl.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I'm using the RabbitMQ Java client API and need some guidance on the proper application shutdown procedure.<br>
<br>
Here's how I start the application:<br>
1-Create a Connection<br>
2-Create different types of consumers, each with its own channel, and call channel.basicConsume("queue", false, consumer)<br>
3-Let it all run<br>
<br>
This works great, but I can't figure out how to cleanly shutdown the application. If I simply close the Connection, each created channel immediately (or soon enough) becomes invalid and any Consumer currently doing some work fails when trying to ack their current message or perform any other action on the channel. I'd like to let the consumers finish whatever message they're processing and then close everything down. I guess I need to keep track of the created Consumers and somehow signal them to stop accepting new messages and after they're all done with their current job, close the connection? Is that possible or is there another way? I haven't found any management methods for the consumer classes to control or query their status.<br>

<br>
The information I found so far is related to manually created threads that poll the queues to process messages. In that case, it's really easy because I can just set a flag on each runnable to exit after processing their current message and join on all the threads before closing the underlying connection. So this leads me to ask, as a side note: are Consumers the way to go to use RabbitMQ in real-world scenarios or should I poll on the queues? It seems to me that Consumers would be the better choice (polling is bad), but if they're less powerful, perhaps they're not a silver bullet in my case.<br>

<br>
Thank you,<br>
Bertrand<br>
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Jason McIntosh<br><a href="https://github.com/jasonmcintosh/" target="_blank">https://github.com/jasonmcintosh/</a><br>573-424-7612</div>
</div>