<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 28, 2013 at 2:04 PM, Matthias Radestock <span dir="ltr"><<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.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 28/10/13 20:40, Graeme N wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, if you've got my script bundle from earlier in the thread, just<br>
update with this script. Use them to build a test cluster, populate 100<br>
queues with 1000 messages each. Then run this script to delete and<br>
recreate all the queues. This always produces new queues for me that<br>
contain old messages. ;)<br>
</blockquote>
<br></div>
Publishing is asynchronous. AFAICT the test node does not guarantee that all published messages have made it to the queues by the time populate_queues terminates. Some messages could still sit in various network or internal (pre-routing) buffers. If you then, concurrently, delete the queues and recreate them, the buffered messages will get routed to the newly created queues.<br>
</blockquote><div><br></div><div>Yeah, I typically wait until the management console reports all messages delivered to all queues, so I'm not just automating running these scripts in a row. I've been assuming that if the management console reports messages are delivered, then this scenario doesn't apply.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That's one explanation. The other possibility is that one of the other issues you reported is somehow causing this. Obviously if rabbit internals are exploding in various interesting ways (indicated by errors getting written to the SASL logs), as is happening in your tests, then all bets are off.<br>
</blockquote><div><br></div><div>Well, when I've been running this, I updated my scripts to do queue deletion linearly (without any shell level parallelism), as should be seen in the updated setup script. In this situation, I'm not seeing it throw a bunch of obvious errors, but when I go to create the new message queues, they show up with some subset of the original messages in them.<br>
</div><div><br></div><div>Graeme<br></div></div></div></div>