[rabbitmq-discuss] Messages as mutex tokens - rewrite or nack

Thu May 30 14:06:12 BST 2013

basic.reject and basic.nack are really only different on the wire.

As you have seen, the AMQP standard states that a server MUST avoid 
redelivering the message to the came channel. In practice we don't do 
that, the message is just reinserted into the queue.

We don't guarantee that we won't change a future version of RabbitMQ to 
be closer to the spec in this regard, but it's certainly not high up our 
list of priorities now. But just in case, you might want to stick to 
your current approach.

Cheers, Simon

On 30/05/13 13:34, Laing, Michael P. wrote:
> Our clusters support apps that do work periodically, e.g. Every few
> seconds or minutes, typically analyzing/reporting the state of other apps.
>
> We run an identical instance of each app connected to each node of the
> cluster. The apps each subscribe to a 'token' mirrored queue which is
> seeded with a single message.
>
> One app gets the message, does its work, waits for the appropriate
> interval, and then republishes the token message to the queue. The next
> app gets the message - they proceed in a round robin fashion.
>
> Today I am reviewing and refactoring this logic, and I wonder if it
> would be better to keep a single token message and just nack it instead
> of rewriting. Nacking is a little simpler.
>
> However, I see in the documentation for BasicReject that the broker may
> not want to deliver the same message within the same channel context;
> does this hold for BasicNack as well?
>
> In a cluster with one node, the above pattern using rewrite works fine.
> Would it still work using nack or would the app have to close the
> channel and resubscribe using a new one (probably too expensive/messy)?
>
> Cheers,
> Michael
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

-- 
Simon MacMullen
RabbitMQ, Pivotal