[rabbitmq-discuss] RabbitMQ 1.7.0 close the cnx when consumer don't ack deliveries during 30s

[Simon MacMullen]

On 15/07/10 15:35, Vincent Barat wrote:
> I got my fix: here is what I do:
>
> 1- I use basicQos() to be sure that the server will not send "too many"
> messages (actually, I have checked that basicQos() does not offers a
> guarantee on the number of un-acknoledged messages sent, since I
> actually receive much more than the parameter I give, but it seems at
> least to limit the amount of messages, maybe there is a bug here ?).

Hi Vincent. I don't think there's a bug in our handling of basic.qos - 
it's been around for a while and a lot of people are using it successfully.

I notice that in onNewChannel():

   @Override
   protected void onNewChannel(Channel channel) throws IOException
   {
     super.onNewChannel(channel);

     /*
      * Configure the channel to send not more than a given amount of 
unacknowledged messages. This
      * avoid at the same time to buffer too many messages (which could 
exhaust memory) and to block
      * in handleDelivery() (which could brake the connection).
      */
     channel.basicQos(capacity);
   }

You invoke channel.basicQos() after super.onNewChannel(). Does 
super.onNewChannel() invoke channel.basicConsume() by any chance? If it 
does so then the server can start sending an unlimited  number of 
messages as soon as it receives this message - it'll only start limiting 
the number it sends out after receiving basic.qos. Therefore it's 
usually better to send basic.qos before basic.consume.

Cheers, Simon

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