[rabbitmq-discuss] Messages as mutex tokens - rewrite or nack
simon at rabbitmq.com
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.
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)?
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
More information about the rabbitmq-discuss