[rabbitmq-discuss] Reliable "publishing"
simon at rabbitmq.com
Tue Dec 20 10:53:33 GMT 2011
On 16/12/2011 8:05PM, Simone Busoli wrote:
> On Fri, Dec 16, 2011 at 14:16, Simon MacMullen <simon at rabbitmq.com
> <mailto:simon at rabbitmq.com>> wrote:
> The only reason your client might not receive a (n)ack for any given
> message would be if the connection goes down
> Exactly, which if you're looking for some degree of reliable delivery is
> something you should take care of as well, right?
> So what I understand - please correct me if I'm wrong - is that neither
> Shovel nor Federation are doing anything with unconfirmed messages (i.e.
> no acks/nacks), so theoretically some messages may be "lost" because
> even if the upstream broker didn't receive an ack for them and will thus
> store them until they're acked (as the plugin wouldn't send one until it
> has received confirm from the downstream broker), there is however no
> one who will issue a recover to the upstream broker to request a requeue
> of those messages.
Recover is only one way to get unacked messages requeued - the
connection going down is another.
In fact "recover" can really be understood as "pretend this connection
So these messages won't be lost.
It is however possible for messages to get duplicated in these
circumstances - for messages where the downstream has confirmed but the
shovel / federation hasn't yet sent on the corresponding ack when the
More information about the rabbitmq-discuss