[rabbitmq-discuss] Exactly Once Delivery

[Tony Garnock-Jones]

Tim Fox wrote:
> To do all of this without being limited by arbitrary cache size, would
> need some kind of "ack of ack"

That's an occasionally-useful optimization, but it really only works well with
message UUIDs (i.e. never repeating a message ID). Even then, in the general
case you're likely to want to bound the time you wait for the message
transmission to complete anyway (consider what happens when an ack or ack-ack
goes missing), it seems simpler (not to mention much less chatty) to me to
avoid ack-acks and go with a Delta-T style timeout-bounded buffer. At that
point you're free to choose any kind of message ID space, including
compressible fixed-length reusable spaces like those in TCP/SCTP etc.

> Like others have said, 100% once and only once delivery doesn't happen.
> To get very near at 100% you can implement stuff like the above, and
> also make sure your storage is highly redundant, also mirrored in
> geographically distributed sites in case the building blows up. Then
> you've got bugs in your own app, device drivers or the operating system
> that screw your once and only once (for example last week I hit a bug in
> the Linux kernel TCP impl which can cause packets to be lost at high
> load) that you might hit well before having to take quantum effects into
> account :)

Amen :-)

Tony