<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>On 3 Nov 2010, at 15:12, Philippe Blayo wrote:<br><br><blockquote type="cite">Hello,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">For our fitnesse tests, we have a thread that consumes messages and is<br></blockquote><blockquote type="cite">interrupted after a time out. It is interrupted most of the time in<br></blockquote><blockquote type="cite">the blocking call to QueuingConsummer.nextDelivery(). We observe that<br></blockquote><blockquote type="cite">there is a pending message that is not taken and not acknowledged :<br></blockquote><br>Is this timeout triggered by your fitnesse tests? Presumably you are looking to limit the time a test takes in the case of failure.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">$ rabbitmqctl list_queues name messages_ready messages_unacknowledged<br></blockquote><blockquote type="cite">Listing queues ...<br></blockquote><blockquote type="cite">STAT_PRINCIPALE 1 1<br></blockquote><blockquote type="cite">...done.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Our consumer receive an InterruptedException via<br></blockquote><blockquote type="cite">ExecutorService.shutdownNow() in queue.take() in the QueuingConsummer.<br></blockquote><blockquote type="cite">We reuse channels on the same connection but not on two concurrent<br></blockquote><blockquote type="cite">threads at a time.<br></blockquote><br>This is to be expected. When using shutdownNow() all worker threads are interrupted and queue.take() is a perfectly interruptible operation. This isn't necessarily a problem because interruption is intended to be a cooperative process between threads. The interruption itself doesn't actually leave the consumer or the server in any bad state. In fact, after the ES has shutdown, you can happily take that same QueueingConsumer and start calling nextDelivery on other threads and it will continue to work.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Is there a better way to close the QueuingConsummer.nextDelivery() ?<br></blockquote><br>That depends on your definition of better :) You could call ExecutorServer.shutdown followed by ExecutorService.waitForTermination(). This will give the worker threads in the ES some time to drain what is left in the queue and exit gracefully.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">-- <br></blockquote><blockquote type="cite">Philippe Blayo & Bruno Thomas<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">rabbitmq-discuss mailing list<br></blockquote><blockquote type="cite"><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br></blockquote><blockquote type="cite"><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br></blockquote><div><br></div></body></html>