[rabbitmq-discuss] Explicit ACKs - Timeout Algorithm? (related: Net::Stomp)

[Tony Garnock-Jones]

Hi Darien,

Darien Kindlund wrote:
> 1) So far, it seems that RabbitMQ will only alter messages that have
> been previously been "acquired" back to "not acquired" ONLY when the
> original consumer's *channel* has been terminated

That's right.

> 2) Is there any reference in the AMQP specification for dealing with
> these situations?  If RabbitMQ does implement some sort of timeout (as
> previously stated), what is the default time delay?

Currently AMQP doesn't have support for configuring such a timeout, and
RabbitMQ doesn't implement one, either. It seems like a useful idea,
though. If it were implemented, I'd imagine that if you didn't
acknowledge a message within the timeout, the server would issue a
channel.close, which would have as a side-effect the rollback of any
transactions and the release of any "acquired" messages.

However, could it be done some other way, avoiding the need for an
extension to the protocol or a change to the server? Perhaps some kind
of watchdog on the client side that throcks the connection when it
notices that the message-processing part of the client is wedged?

> 3) Is it possible that in order to achieve this type of behavior, you
> have to use transactions (tx) or distributed transactions (dtx) in
> RabbitMQ?

I don't think so -- in a way, ack-required messages even on ordinary
non-TX channels are like tiny, single-operation transactions that can
rollback (on channel close) or commit (on ack).

Regards,
  Tony
-- 
 [][][] Tony Garnock-Jones     | Mob: +44 (0)7905 974 211
   [][] LShift Ltd             | Tel: +44 (0)20 7729 7060
 []  [] http://www.lshift.net/ | Email: tonyg at lshift.net