[rabbitmq-discuss] Consumers stopped consuming messages

[Simon MacMullen]

Hi Florence. As far as I can see this is reasonable. It's always worth 
setting the prefetch count when using basic.consume (add a line like:

channel.basicQos(100);

before the channel.basicConsume line in order to ensure you never have 
more than 100 messages queued up in your QueueingConsumer). However, I 
don't think that's your problem.

I assume you have checked that the consumers are idle and waiting for 
message deliveries (with Ctrl+Break / SIGQUIT). Does anything appear in 
the server logs when consumers stop consuming?

Cheers, Simon

On 20/07/10 11:38, Florence Chabanois wrote:
>
> Hi Simon (sorry for answering twice),
>
> Thanks for your reply. We didn't find how to configure the basic.qos in
> the java API. Here is our spike code :
>
> private void consommeEvenements() throws IOException {
> Channel channel = acteurRabbitMQ.chaines.get(QUEUE_PRINCIPALE);
> QueueingConsumer consumer = new QueueingConsumer(channel);
> channel.basicConsume(QUEUE_PRINCIPALE.name(), consumer);
> while (channel.isOpen()) {
> QueueingConsumer.Delivery evenementBrut = null;
> EvenementStat evenementRecu = null;
> try {
> evenementBrut = consumer.nextDelivery();
> evenementRecu = decode(evenementBrut);
> logger.info("evenement recu : " + evenementRecu);
> simuleErreurBaseDeDonnees(evenementRecu);
> } catch (IOException e) {
> logger.fatal("Soucis de deserialize", e);
> } catch (Exception e) {
> logger.error("Soucis d'écriture en base", e);
> if (evenementRecu.estReinjectable()) {
> logger.info("--> renvoi de " + evenementRecu);
> programmeRepublication(evenementRecu);
> } else {
> logger.info("--> DEAD LETTER " + evenementRecu);
> acteurRabbitMQ.publie(evenementRecu, QUEUE_DEAD_LETTER);
> }
> }
> boolean ackMultiple = false;
> final long deliveryTag = evenementBrut.getEnvelope().getDeliveryTag();
> logger.info("ACK " + deliveryTag);
> channel.basicAck(deliveryTag, ackMultiple);
> }
> acteurRabbitMQ.ferme();
> }
>
> Yet, I'm not sure the basic.qos is the issue as long as the 6 consumers
> sometimes keep consuming the messages during the 10 minutes bench, and
> sometimes not.
>
> When the problem occurs, the list_queues option displays that the queue
> starts growing because the "active" (the ones that keep on consuming)
> consumers cannot insert in DB the overall messages load fast enough.
>
> Cheers,
> Florence.
>
>
> --- En date de : *Mar 20.7.10, Florence Chabanois
> /<flocha2000-agile at yahoo.fr>/* a écrit :
>
>
>
>         De: Simon MacMullen <simon at rabbitmq.com>
>         Objet: Re: [rabbitmq-discuss] Consumers stopped consuming messages
>         À: rabbitmq-discuss at lists.rabbitmq.com
>         Date: Mardi 20 juillet 2010, 11h26
>
>         On 20/07/10 09:55, Florence Chabanois wrote:
>         <snip>
>          > We noticed that /*sometimes*/, consumers hang (well, they are not
>          > blocked, but they dont consume messages anymore). We can see that
>          > because each consumer save around 100 msg/sec in database, so
>         when one
>          > is stopping consumming, the overall messages saved per
>         seconds in DB
>          > fall down with the same ratio (if let say 3 consumers stop,
>         we fall
>          > around 600 msg/sec to 300 msg/sec).
>         <snip>
>          > FYI there has been a similar issue here, but it wasn't resolved :
>          >
>         http://old.nabble.com/Consumer-stop-to-receive-messages-but-continue-listening-queue-problem.-td27872888.html
>
>         Hi Florence. One possibility that was considered in the linked
>         thread was that all the messages were being sent to some
>         consumers due to basic.qos not being set (in the absence of
>         basic.qos, Rabbit is allowed to do that).
>
>         So:
>
>         * Are you setting the basic.qos prefetch count?
>         * What does rabbitmqctl lists_queues say about he queue when the
>         system is in this state?
>         * Are you able to post your spike code anywhere?
>
>         Cheers, Simon
>
>         -- Simon MacMullen
>         Staff Engineer, RabbitMQ
>         SpringSource, a division of VMware
>
>         _______________________________________________
>         rabbitmq-discuss mailing list
>         rabbitmq-discuss at lists.rabbitmq.com
>         https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


-- 
Simon MacMullen
Staff Engineer, RabbitMQ
SpringSource, a division of VMware