[rabbitmq-discuss] Pub/Sub Guaranteed Delivery

Tue Sep 25 21:02:49 BST 2012

On Tue, Sep 25, 2012 at 5:55 PM, Francisco Aguiar Zanfranceschi
<zanfranceschi at gmail.com> wrote:
> Thanks for your reply, Alexis. I guess what you said I can see in a non
> pub/sub (using fanout) scenario (persistent, durable, ack)... Am I
> understanding your response right?

No, in the sense that persistent, durable, ack are all things that
work with Rabbit pub/sub.  This example is not using fanout:

http://www.rabbitmq.com/tutorials/tutorial-four-python.html

> I've searched extensively for this
> answer, but I found there is no out of the box solution in RabbitMQ (and
> most of other queue solutions), so I'm trying to find good practices to
> achieve it -- pub/sub technique to "guarantee" messages are delivered to all
> subscribers. I'm trying to avoid the idea of building a custom lightweight
> middleware (although my diagram represents one in some sense).
>
> I couldn't find the post you mentioned -- would you mind pointing it to me,
> please?

It's this one: http://www.rabbitmq.com/tutorials/tutorial-four-python.html

alexis

> Thanks again.
>
> Francisco
>
>
> On Tuesday, 25 September 2012 13:10:47 UTC-3, Alexis Richardson wrote:
>>
>> On Tue, Sep 25, 2012 at 1:10 PM, Francisco Aguiar Zanfranceschi
>> <zanfra... at gmail.com> wrote:
>> > I'd like to say that's probably easier if I ask what's the best way to
>> > guarantee all subscribers receive all messages even when they go offline
>> > using RabbitMQ. I imagine all of us had that challenge or will have it
>> > sooner or later. I'm sorry to kind of bump this discussion.
>>
>> You want to make sure that each consumer (subscribed client) can have
>> its messages held in a queue, while it is offline, so that it can get
>> the messages when it reconnects.  This is achievable using the pattern
>> I linked to in my previous post on this thread.
>>
>> Then, you need to make sure that when it does connect, the messages
>> get to the consumer and only after you know that happened, is the
>> message deleted from the queue.  This is achievable by using
>> acknowledgement.
>>
>> Does this answer your question?
>>
>> It is also important to understand the failure scenarios clearly,
>> whenever words like "guarantee" are bandied about ;-)