<meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; ">I&#39;m working with RabbitMQ and wondering if anyone has some suggestions to simplify my design or follow more rabbit-specific idioms.<br>
<div><br></div><div>Currently we receive messages in a packaged format, and dump those into a single queue for unpackaging later (so far so good).</div><div><br></div><div>We have a listener on that queue that unpacks these messages, and dumps them into a queue-per-customer kind of approach. We have ~15,000 potential customers, so we&#39;ve approached it as follows:</div>
<div><br></div><div>�- Every so often, do a call to the management API to get a list of queues that have messages ready</div><div>�- iterate over the queues and process any messages waiting there (in a separate thread pool)</div>
<div>�- delete the queue if it&#39;s empty</div><div><br></div><div>Since the scheduled management API approach isn&#39;t a very realtime operation (especially with a few thousand queues - it can be very slow) we also have an approach where we have a &#39;queue-updated&#39; queue, which we listen on and when a message is received there, we process the appropriate queue. Since processing the queue entries can take a long time, we don&#39;t tie the &#39;queue-updated&#39; message success to the actual processing of the consumer queues, but use them as hints that we should check a particular consumer queue.</div>
<div><br></div><div>Is there a better/simpler approach? Perhaps a listener on the exchange itself? The queue-per-customer approach is advantageous for us given how we interact with the data - we can batch up messages for the same customer and save a lot of processing and I/O.</div>
<div><br></div><div>Thanks,</div><div><br></div><div>�-Dave</div></span><br>-- <br>Dave LeBlanc &lt;<a href="mailto:david.leblanc@gmail.com">david.leblanc@gmail.com</a>&gt;<br><br>