[rabbitmq-discuss] Pub/Sub -- block publisher until all acks received from subscribers?

[Nick Martin]

Hi Emile,
Yes, you understand my situation correctly.

I thought about a solution to eliminate the need for pause messages at all
-- and draining the queue is the same conclusion I came to also. This would
in effect act as a way to pause the workers. This solution presents its own
issue though. Because I want to just temporarily pause, not actually throw
away the work, how do I reliably store the contents of the queue once it
has been drained?

Perhaps something like moving the messages from the original queue to a
different, backup queue and not acking the messages from the first queue
until the backup is in place? That would seem to reliably store the
contents. Then I could do the opposite to restore the original queue. I
could also store them somewhere else, like a database. I am concerned that
this approach leads to its own set of thorny problems and corner cases
though. I suspect I am missing some potentially devastating corner case.

I don't really want to become a messaging expert; I was hoping someone else
may have already implemented something that I could just use.

What do you think? Is there something out there that could help me.

Nick



On Sun, Nov 4, 2012 at 3:02 PM, Emile Joubert <emile at rabbitmq.com> wrote:

> Hi Nick,
>
> On 01/11/12 15:50, Nick Martin wrote:
> > > Can the same aim be achieved in another way by taking a larger view
> > > of the system?
> > I'm not sure. Do you have any suggestions?
>
> If I understand correctly you want a way of communicating start/stop
> control messages to all workers throughout the system.
>
> You could employ an elaborate RPC scheme to accomplish this, but it
> would be simpler to let the work queue drain instead of sending a stop
> message, assuming you are using a single worker queue. If necessary you
> could delete the work queue and have the workers take special action
> upon receipt of the basic.cancel message that will be sent.
>
> To start work you could have the publisher re-instate the work queue and
> instruct workers to periodically attempt resubscribing to the work queue.
>
>
>
>
> -Emile
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121105/7ee43b79/attachment.htm>