[rabbitmq-discuss] Reliable "publishing"

[Simon MacMullen]

Yes, this is a reasonable approach. Shovel / federation both chain acks 
and confirms together, so that one broker or the other is always 
responsible for the message.

As to your second question: the real answer is likely to be specific to 
your application. But messages should not remain unconfirmed 
indefinitely. The only reason your client might not receive a (n)ack for 
any given message would be if the connection goes down.

Cheers, Simon

On 15/12/11 00:15, Simone Busoli wrote:
> Hi, I'm trying to achieve some degree of reliability in publishing of
> messages in order to guarantee that a message published by some peer
> gets to the broker. I am using two strategies here:
>
>     * wrap access to the channel for publishing so that publishes done
>       by the application are first enqueued in a in-memory queue and
>       then published to the broker only when it is known to be
>       reachable. I am using the .NET client ConnectionShutdown events to
>       figure out whether the broker is reachable, and rescheduling
>       connection in case of failure. I have one thread emptying the
>       in-memory queue which runs when the connection is established and
>       pauses when it is not available
>     * use publisher confirms and keeping track of the messages published
>       but not acked or nacked by the broker
>
> A couple of questions:
>
>     * Is this a sensible approach? I have looked into how Shovel and
>       (briefly) Federation handle publisher confirms when enabled but I
>       didn't spot anything being done with unconfirmed messages except
>       for removing them as soon as an ack from the broker arrives
>     * What should I be doing with unconfirmed messages which have
>       remained unconfirmed for some time? The broker is supposed to
>       guarantee that either an ack or nack is sent, but what if the peer
>       for any reason doesn't receive them for one or more messages? The
>       unconfirmed deliveries will stay in the local
>       collection/set/[wherever it makes sense to keep them in memory]
>       and you would have to handle them first or then
>
> Thanks
>
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


-- 
Simon MacMullen
RabbitMQ, VMware