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

[Vincent Barat]

  Hi again,

You are definitively right!  I will update my code that will work 
perfectly now I'm sure :-)

Thank you so much for your help!

Le 15/07/10 17:09, Simon MacMullen a écrit :
> 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
>