[rabbitmq-discuss] Fwd: question on the faq
gsim at redhat.com
Mon Jan 5 22:18:18 GMT 2009
Matthias Radestock wrote:
> 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
>> 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
>>> ... 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.
More information about the rabbitmq-discuss