<div dir="ltr"><p>Hi Matthias,</p><p>Thanks for responding.<br></p><p>There is a couple of projects at work that will require an async system based on message queues. I don't want to lose anything and I do want to handle cases in which the message was consumed (and not acked yet) and something bad happend. In which case, I want to ack a message only when I know for sure that the actions that this message triggered finished correctly.</p>
<p>So, the current behavior is well suite for me.</p><p>Regarding the blocking "GET" commands, I read about Kesterl (in the link I gave below) and thought its an interesting approach to make pulling a bit more efficient instead of sending the "puller" back to a short sleep.</p>
<p>That's basically the only scenario. I don't think its too important. What was more important to me was understanding the exact Ack semantics (which is implemented exactly as I want it to be :-) ).</p><p>With the new command line tool that allows getting the queue length, I can easily write a script to let Nagios alert me if the rate of messages going in is higher than the rate of them coming out.</p>
<p>Eran</p><br><div class="gmail_quote">On Fri, Mar 13, 2009 at 2:24 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Eran,<div class="im"><br>
<br>
Eran Sandler wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In a consumer pull model, where consumers pull the queue once in a while (without subscription) and you have multiple consumer, if a consumer pulls a message (without auto ack) and doesn't ack it can another consumer still get it or is it marked in a certain way until its acked and deleted? <br>
</blockquote>
<br></div>
The AMQP ack model for subscriptions and "pull" are identical. In both cases the message is kept on the server but is unavailable to other consumers until it either has been ack'ed (and gets removed), nack'ed (with basic.reject; though RabbitMQ does not implement that) or the channel/connection is closed (at which point the message becomes available to other consumers).<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Assuming when a message is pulled and not acked yet and no other consumer can pull it until its either acked or rejected back to the queue, will it have a certain timeout that it was pulled and wasn't acked for X amount of time?<br>
</blockquote>
<br></div>
There is no timeout on waiting for acks. Usually that is not a problem since the common cases of a missing ack - network or client failure - will result in the connection getting dropped (and thus trigger the behaviour described above). Still, a timeout could be useful to, say, deal with alive but unresponsive consumers. That has come up in discussion before. Is there a specific use case you have in mind that requires such functionality?<br>
<br>
<br>
Regards,<br><font color="#888888">
<br>
Matthias.<br>
</font></blockquote></div><br></div>