You may want to investigate whether shovel is a better fit in this situation.<div><br></div><div>For example: run the shovel on the current upstream, predeclare the queues/bindings in the shovel config so messages will pool, and then push to your downstream, rather than using federation, or dedicated consumers etc.</div>
<div><br></div><div>When the upstream restarts and auto-magically loses its queues, the shovel plugin will redeclare the queue/bindings on boot, and whola! Your messages will still be routed and pooled before being pushed downstream by the shovel.<br>
<div><br></div><div>Just an idea.</div><div><br></div><div>- Brendan<br><br><br><div class="gmail_quote">On Tue, Apr 17, 2012 at 11:32 PM, James Carr <span dir="ltr"><<a href="mailto:james.r.carr@gmail.com">james.r.carr@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>One of the things keeping me up at night lately is a worry that our federation links will break, the broker will lose its queues someway and we'll wind up with messages being published that just get dropped.�</div>
<div><br></div><div>Is there a way we could define some kind of queue that is setup by default? The only other thing I could think is to just define alternate-exchanges for every exchange, slap a queue on it and set a consumer on it that simply republishes when federated links are established.�</div>
<div><br></div><div>Other ideas? The approach I came up with feels rough.�</div><div><br></div><div><br>Thanks,<br>James</div><div>
<br></div>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br></div></div>