[rabbitmq-discuss] Fwd: question on the faq

Tue Jan 6 12:41:53 GMT 2009

Matthias Radestock wrote:
> Gordon Sim wrote:
>> Matthias Radestock wrote:
>>> Perhaps, but who should this condition be signalled to? I'd argue the 
>>> *consumers* should be told about it. After all, the queue may vanish 
>>> long after anyone has published a message to it. Conversely, if 
>>> nobody ever tries to consume messages from the queue then the fact 
>>> that it once existed and then vanished is of little interest to anybody.
>>
>> Notifying consumers is all well and good. However there may not be any 
>> consumers at the point the message is published. An important role of 
>> the queue is to accept responsibility for the message from the 
>> publishing client until that can be transfered onto the receiving client.
> 
> In the non-tx case, how does a publisher know when the server has 
> accepted responsibility?

In 0-9 it cannot due to the lack of any acknowledged publication (a 
significant failing of that version of the specification).

>> The whole concept of the queue vanishing is a bit alien to me and 
>> seems to make reasoning about reliability more difficult.
> 
> RabbitMQ tries to isolate failures, in order to make the system more 
> reliable overall. What's the alternative? Bring down the entire server 
> every time something unexpected happens?

No; but certainly making the application aware of the problem is important.

If a transaction containing a publish operation commits successfully and 
results in a persistent message being enqueued on a durable queue, I 
view that as a contract with the publisher that the message will be 
retained for delivery to potential subscribers as long as the device on 
which durable data is stored functions correctly. That for me is 
essentially the durability guarantee.

If there is any doubt about that at the point of committing the 
transaction then the transaction should in my view be aborted.