Trying to understand the difference between "Ready" and "Unacked" messages with one consumer.

[Sgoodman]

Hi, 

(I am using the c# example on the RabbitMQ site).

I declared a queue and a publisher/consumer

consumer.Received += (model, ea) =>
{
 ... 
};

If I put a breakpoint inside the 'Received' function and I publish a message, the breakpoint is hit successfully.

The message is moved to "Unacked", and that makes sense as my app has indeed received it but has not yet acked it.

Now, if I send another message, (while my first breakpoint is still holding firm), the new message is also flagged as "Unacked".

That does not make sense, why would the second message be Unacked? Who was is sent to?

Effectively my receiver app is still busy "processing" the first message, who is now busy with the second one?

Surely it should just be in "Ready" until any of the consumers are actually able to handle it, (or even a new consumer that might start afterward).

If all messages are "Unacked" by default, what's "Ready" for?

This matters as x-message-length is only applied to "Ready" messages, not to "Unacked" messages, (a bit weird, but anyway).

Any suggestions as what I might be doing wrong?

Thanks in advance

Simon

[Luke Bakken]

Hi Simon,

In your case, the second message has been delivered to your client and is either waiting in the TCP buffer on the client machine or perhaps it has already been parsed by the client library, but can't raise the event because you have blocked the application with your breakpoint.

You should set prefetch to 1 in your test, and re-try it. You will see different behavior that confirms what I have explained.

Thanks,

Luke

[Sgoodman]

Thanks a lot Luke, I had my prefetch set to 1000

I wonder if there is a way of calculating what a 'good' prefetch should be.

I guess it matters to how many messages I am prepared to lose.

Thanks

Simon

[Karl Nilsson]

You won't lose any messages using manual acks as as soon as RabbitMQ detects the connection you are using is closed it will return any unacked messages to the queue to be consumed by the next consumer.

Cheers

Karl

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/75c988cf-033f-47e1-a486-78495b8c2fac%40googlegroups.com.

--

Karl Nilsson

Pivotal/RabbitMQ

[Luke Bakken]

Hi Simon,

Like Karl said, as long as your code manually acknowledges messages you won't lose them if the connection is lost and they are in-flight. RabbitMQ will re-enqueue them.

As far as a "good" prefetch value, you should take into consideration how fast you process messages, whether or not you process them on other threads, etc. If your message bodies are large, you probably don't want a large prefetch.

Running benchmarks is always the best way to determine a good value.

Thanks,

Luke

[Sgoodman]

Thanks a lotKarl and Luke

Very interesting.... I will play around with numbers to see when there is a major difference

My processing is very fast, but I do not see the point in prefetching more than 10 or so messages at a time

Simon

[Michael Klishin]

Relevant doc guide: [1].

1. https://www.rabbitmq.com/confirms.html