<div dir="ltr"><div class="gmail_quote">On Wed, Mar 2, 2011 at 7:24 PM, Fabio Margarido <span dir="ltr"><<a href="mailto:fabiomargarido@gmail.com">fabiomargarido@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Mar 2, 2011 at 14:12, Alexis Richardson <<a href="mailto:alexis@rabbitmq.com">alexis@rabbitmq.com</a>> wrote:<br>
>> Or failing that, perhaps a bit like the "real time record" model, such as used for financial data, where a consumer gets the last published update for a topic. IIRC the guys at Rabbit HQ did some work on an exchange which persists the last update to a topic - what became of that? This would fit the problem definition quite well, I think.<br>
</div></blockquote></div><br><div>you can make one queue named - conifg_data</div><div>and always call basic_reject() on new config messages (with newer versions or such...)</div><div>on old config messages call basic_ack and they will be gone...</div>
<div><br></div><div>don't forget to make the queue durable and the messages�persistent�if that is needed.</div></div>