[rabbitmq-discuss] RabbitMQ 1.7.0 close the cnx when consumer don't ack deliveries during 30s
vbarat at ubikod.com
Thu Jul 15 20:43:37 BST 2010
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
>> 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():
> protected void onNewChannel(Channel channel) throws IOException
> * 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).
> 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
> Cheers, Simon
More information about the rabbitmq-discuss