[rabbitmq-discuss] RabbitMQ 1.7.0 close the cnx when consumer don't ack deliveries during 30s
simon at rabbitmq.com
Thu Jul 15 16:09:07 BST 2010
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():
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 basic.consume.
Staff Engineer, RabbitMQ
SpringSource, a division of VMware
More information about the rabbitmq-discuss