On 3 Nov 2010, at 15:12, Philippe Blayo wrote:
> Hello,
>>> For our fitnesse tests, we have a thread that consumes messages and is
> interrupted after a time out. It is interrupted most of the time in
> the blocking call to QueuingConsummer.nextDelivery(). We observe that
> there is a pending message that is not taken and not acknowledged :
Is this timeout triggered by your fitnesse tests? Presumably you are looking to limit the time a test takes in the case of failure.
>> $ rabbitmqctl list_queues name messages_ready messages_unacknowledged
> Listing queues ...
> STAT_PRINCIPALE 1 1
> ...done.
>> Our consumer receive an InterruptedException via
> ExecutorService.shutdownNow() in queue.take() in the QueuingConsummer.
> We reuse channels on the same connection but not on two concurrent
> threads at a time.
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.
>> Is there a better way to close the QueuingConsummer.nextDelivery() ?
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.
>> --
> Philippe Blayo & Bruno Thomas
> _______________________________________________
> rabbitmq-discuss mailing list
>rabbitmq-discuss at lists.rabbitmq.com>https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss