[rabbitmq-discuss] Fwd: question on the faq

Mon Jan 5 21:38:11 GMT 2009

Gordon,
Gordon,

Gordon Sim wrote:
> I'm not sure I follow you. If, as I understood your earlier comment to 
> imply, the various transactional operations cannot be atomically 
> aborted, it would seem to me that it is not ACID under either 
> interpretation.
> 
> E.g. if a transaction where I publish a message and acknowledge another 
> is aborted, is it possible that the published message is delivered to a 
> subscriber of some matching queue and the acknowledged message is left 
> on the queue and is subsequently redelivered to another subscriber? If 
> so it is not atomic.

The above cannot happen when the abort was caused by a fault or 
tx.rollback. It can only happen in the event of node or communication 
failure in a clustered set up when performing a tx.commit, though 
arguably the error in that case is signalling a breakdown of the tx 
mechanics ("all bets are off") rather than a controlled tx abort.

> Personally I'm not convinced the stream/resource distinction alters the 
> issue which for me relates to the success of operations. A successful 
> publish operation causes a message to become available for delivery to 
> subscribers on all matching queues; a successful ack operation prevents 
> the referenced message from being redelivered. Atomicity means that 
> either all the are 'successful', or none of them have any effect.

The spec has nothing to say regarding the semantics of "successful 
publish", except in regard to a few obvious cases (e.g. non-existence of 
the exchange) and in the context of the mandatory/immediate flags, which 
don't actually cause the publish to fail (a basic.return is not a failure).

>> And because ...
>>
>>> Routing to a queue is acceptable streaming behaviour.  So
>>> if the queue fails after being routed to, then it is not unreasonable
>>> to treat something as having 'happened'.
> 
> A bug (or indeed some hardware failure) may prevent a message from being 
> accepted by the queue. Thats a different case from the queue not 
> existing. In the current AMQP routing model publishing a message for 
> which no binding matches is not an error, but the failure or a bound 
> queue to accept a message routed to it is in my view an error and should 
> be signaled as such.

AMQP does not define the latter case as an error. We can debate whether 
it should, but in RabbitMQ we decided that the disappearance of a queue 
- for whatever reason, including as a result of some fault during the 
handling a basic.publish - does not result in a failure of ordinary 
publishes, though for mandatory/immediate publishes a basic.return will 
be issued if none of the bound queues accept the message.

>> ... arguably, to be fully consistent with the second interpretation a 
>> tx.commit (and rollback) should *succeed* even if some of the queues 
>> to which messages/acks were delivered disappears. RabbitMQ's tx.commit 
>> currently returns an error for this, which is something we may want to 
>> change.
> 
> If the queue is explicitly deleted by the application, I think thats 
> fair enough. If it 'disappears' due to some failure condition I think 
> that should cause an error which would in turn abort the transaction.

That's certainly a valid point of view. However, there is also a case 
for saying that queues are of no concern to publishers, only consumers, 
since publishers never address them directly. One problem with the spec 
is that there currently is no way for *consumers* to be notified of the 
death/deletion of a queue, which imho would be far more useful.

Matthias.