<br><br><div class="gmail_quote">On Mon, Jun 8, 2009 at 12:11 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@lshift.net">matthias@lshift.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Keith, Jason,<br>
<br>
Keith Irwin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Jun 5, 2009, at 9:11 AM, Jason J. W. Williams wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
when you restart the node the queue data won't auto replay into the cluster. You'll have to do that manually.<br>
</blockquote>
<br>
Are you saying that if an instance of RabbitMQ does down and is brought back up, its persistent messages won't be delivered when a consumer re-attaches? (I'm not sure what you mean by "manually".)<br>
<br>
If that's the case, that seems quite broken and not fault-tolerant at all.<br>
<br>
Surely, I'm misunderstanding.....<br>
</div></blockquote>
<br>
Persisted messages *do* get re-queued automatically on the appropriate durable queues when a node restarts.</blockquote><div><br></div><div>That's good to know! In my research (thus far), about the only AMQP implementation I know of that does full replication across a cluster (or claims to), is Apache QPID. I'm trying to convince myself that trusting anyone's guaranteed messaging strategy is probably not that wise.</div>
<div><br></div><div>Keith</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Jason, did that not work for you? If so, a test case would be appreciated.<br>
<br>
<br>
Regards,<br><font color="#888888">
<br>
Matthias.<br>
</font></blockquote></div><br>