[rabbitmq-discuss] Fwd: question on the faq

[Gordon Sim]

Matthias Radestock wrote:
> 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).

I'm not sure I agree. The semantics of an exchange are clearly defined 
as routing a message to any queue with a matching binding. Failure to do 
so is in my view fairly obviously 'unsuccessful'. Not finding a matching 
binding is a separate case of course and is not an error.

>>> 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.

I don't believe it is valid for a queue to disappear due to some 
internal fault. That to me is a bug and outside the scope of the 
specification.

>>> ... 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. 

True, but a system as a whole needs to be able to rely on the semantics 
of an exchange and the lifecycle of the queue. I think what confuses me 
is the notion of a queue vanishing due to some unspecified error, and I 
would feel very uncomfortable having the broker simply continue without 
signaling that potentially catastrophic violation of the specified 
semantics of a broker.