Hi Emile,<div>Yes, you understand my situation correctly.</div><div><br><div>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? </div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>What do you think? Is there something out there that could help me.</div>
<div><br></div><div>Nick</div><div><br></div><div><br><br><div class="gmail_quote">On Sun, Nov 4, 2012 at 3:02 PM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nick,<br>
<div class="im"><br>
On 01/11/12 15:50, Nick Martin wrote:<br>
> > Can the same aim be achieved in another way by taking a larger view<br>
> > of the system?<br>
> I'm not sure. Do you have any suggestions?<br>
<br>
</div>If I understand correctly you want a way of communicating start/stop<br>
control messages to all workers throughout the system.<br>
<br>
You could employ an elaborate RPC scheme to accomplish this, but it<br>
would be simpler to let the work queue drain instead of sending a stop<br>
message, assuming you are using a single worker queue. If necessary you<br>
could delete the work queue and have the workers take special action<br>
upon receipt of the basic.cancel message that will be sent.<br>
<br>
To start work you could have the publisher re-instate the work queue and<br>
instruct workers to periodically attempt resubscribing to the work queue.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>