[rabbitmq-discuss] Acknowledged Messages Requeued

Mon Nov 14 10:28:22 GMT 2011

-- Ben, are you supplying the correct deliveryTag to the BasicAck?

Yes, I'm passing into BasicAck the DeliveryTag property on the
BasicDeliverEventArgs class that is returned from the Dequeue method.

Kind Regards,

Ben

On Fri, Nov 11, 2011 at 9:33 PM, Simone Busoli <simone.busoli at gmail.com>wrote:

> Ben, are you supplying the correct deliveryTag to the BasicAck?
> On Nov 11, 2011 6:44 PM, "Ben Lewis" <stuckinwigan at gmail.com> wrote:
>
>> Hi Emile,
>>
>> Thanks for the response. Here's the output with from the rabbitmqctl
>> command at different stages:
>>
>> First, with me ack'ing the messages:
>>
>> Prior to starting consumer
>> ------------------------
>> Listing queues ...
>> Test.ItemProcess    67645    0
>> ...done.
>>
>> As consumer is consuming, just reboot rebooting broker
>> ------------------------
>> Listing queues ...
>> Test.ItemProcess    42936    1
>> ...done.
>>
>> After broker rebooted and RabbitMQ started
>> ------------------------
>> Listing queues ...
>> Test.ItemProcess    67645    0
>> ...done.
>>
>> With noack=true the messages are delivered to the client quicker than I
>> can reboot the broker, but when it comes back up the queue is empty with 0
>> unacknowledged messages.
>>
>> I'm not using transactions (I put a seperate console app together to test
>> this) and I do want to persist and acknowledge the message. I've stepped
>> through my code in debug and its hitting the BasicAck method.
>>
>> Kind Regards,
>>
>> Ben
>>
>> On Fri, Nov 11, 2011 at 4:10 PM, Emile Joubert <emile at rabbitmq.com>wrote:
>>
>>> Hi Ben,
>>>
>>> On 11/11/11 15:12, Ben Lewis wrote:
>>> > I have got a direct exchange feeding a durable queue, if I load say
>>> > 50,000 messages onto the queue and then start a consumer to work
>>> through
>>> > those item's.
>>> >
>>> > My consumer creates the connection, then creates the model (I'm using
>>> > .NET) and sets the Qos prefetch count to 1, then calls BasicGet,
>>> > processes the message, sends an ack (BasicAck), then enumerates until
>>> > BasicGet returns null. Finally disposing the model and closing the
>>> > connection.
>>>
>>> You don't need to set QoS if you retrieve messages synchronously
>>> (BasicGet). QoS makes sense with BasicConsume. That is not the cause of
>>> your trouble though.
>>>
>>> > If I restart the host I have the RabbitMQ broker running on (Windows)
>>> > after processing and ack'ing 40,000 messages while my consumer is
>>> > working through the remaining items, when the RabbitMQ broker comes
>>> back
>>> > online the 40,000 messages are redelivered (even though they were
>>> > acknowledged).
>>> >
>>> > Is this supposed to happen?
>>>
>>> No. Acknowledged messages are forgotten about by the broker, so you
>>> should not be seeing them again. What is the output of
>>>
>>> rabbitmqctl list_queues name messages_ready messages_unacknowledged
>>>
>>> before and after the restart? Is it possible that you are somehow not
>>> acknowledging the messages? Do you get the same result if you use the
>>> noAck flag of BasicGet?
>>>
>>> If you are using transactions and failing to commit the transaction then
>>> you could see apparently acknowledged message reappearing - is that a
>>> possibility?
>>>
>>> > If this is by design, any suggestions or advice on how I can minimise
>>> > the number of redelivered messages if the broker dies/restarts?
>>>
>>> If you don't care about persisting messages then you can publish the
>>> messages in non-persistent mode (set the delivery mode in the basic
>>> properties to 1).
>>>
>>>
>>> -Emile
>>>
>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111114/38f62e16/attachment.htm>