[rabbitmq-discuss] Reliable "publishing"

Busoli, Simone Simone.Busoli at ferrari.com
Tue Dec 20 16:19:51 GMT 2011

Indeed, the messages are not lost, but at least lost until the connection eventually goes down and then up once again, which does not necessarily happen frequently and not something you would be doing for the purpose of recovering messages which for some reason haven't been (n)acked, right? Therefore I'm wondering whether a mechanism, perhaps an options of the shovel and federation plugins (every x messages, every x seconds, ...), to process messages which have remain unconfirmed for some time should be introduced.

> -----Original Message-----
> From: rabbitmq-discuss-bounces at lists.rabbitmq.com [mailto:rabbitmq-
> discuss-bounces at lists.rabbitmq.com] On Behalf Of Simon MacMullen
> Sent: martedì 20 dicembre 2011 11:54
> To: Simone Busoli
> Cc: rabbitmq-discuss at lists.rabbitmq.com
> Subject: Re: [rabbitmq-discuss] Reliable "publishing"
> 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 went
> down".
> 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 connection
> dies.
> Cheers, Simon
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Questo messaggio è da intendersi esclusivamente ad uso del destinatario e può contenere informazioni che sono di natura privilegiata, confidenziale
o non divulgabile secondo le leggi vigenti. Se il lettore del presente messaggio non è il destinatario designato, o il dipendente/agente responsabile
per la consegna del messaggio al destinatario designato, si informa che ogni disseminazione, distribuzione o copiatura di questa comunicazione è 
strettamente proibita anche ai sensi del decreto legislativo 196/03 . Se avete ricevuto questo messaggio per errore, vi preghiamo di notificarcelo
immediatamente a mezzo e-mail di risposta e successivamente di procedere alla cancellazione di questa e-mail e relativi allegati dal vostro sistema.
This message is intended only for the use of the addressee and may contain information that is privileged, confidential and exempt from 
disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly 
prohibited. If you have received this e-mail in error, please notify us immediately by return e-mail and delete this e-mail and all attachments from 
your system.

More information about the rabbitmq-discuss mailing list