Thanks, Ben, I will take a look and give you some feedback.<br><br>In the meantime, I have done the following:<br><ul><li>Changed my consumer code (I use the term "consumer" loosely as "anything that eats the output of a producer") to use basic.get instead of basic.consume. Actually, it's set up so that I can select basic.get or basic.consume behavior at run-time. I didn't want to throw away working basic.consume code :)<br>
</li><li>Changed the process that creates consumers so that it now creates one channel per consumer. Previously, there was one channel only for all consumers. One-channel-per-consumer was the only way I could get the code to work with the network client; in the one-channel scenario I was getting back responses to messages destined for different consumers. I assume that with your changes I will be able to again use one channel for all consumers.<br>
</li><li>I tested with 50 queues (each with its own consumer and channel) and it seemed reasonably performant, even with the get. I need to try a full-blast test soon.<br></li></ul>Again, thanks for your help and patience, and do let me know if you see any merit in the rbmq_admin module I wrote, or if maybe you guys are releasing an official one.<br>
<br>Regards,<br>Ed<br><br><div class="gmail_quote">On Fri, May 9, 2008 at 7:07 PM, Ben Hood <<a href="mailto:0x6e6562@gmail.com">0x6e6562@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ed,<div class="Ih2E3d"><br>
<br>
On 8 May 2008, at 21:11, Ben Hood wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
<br>
On 8 May 2008, at 15:04, Edwin Fine wrote:<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Thanks for looking into this. In the "real" code, all the setup is actually done within a single Erlang process, and the only thing the consumers do is handle the basic.deliver, as well as any basic.consume_ok or basic.cancel_ok messages that may arise. In the test code, I rearranged some things specifically to be done concurrently, which I now see was a mistake. However, this is a bug in the test code, not in the production code. I will change the test code so that there is no concurrent work being done on a channel other than responding with basic.ack to basic.deliver messages.<br>
</blockquote>
<br>
I've begun a discussion on this topic and it looks like we will add the intelligence to the amqp_channel module to be able to serialize concurrent RPC requests to the channel. I understand that you have a workaround anyway, but on reflection, it seems like a good idea to put this capability into the client. will let you know when it is done.<br>
</div></blockquote>
<br>
This feature is now implemented in the trunk of the repo. There is also a test case to test the serialization of concurrent RPC requests.<br>
<br>
I will now look into the next 2 issues you raised.<br>
<br>
BTW, I am also in the process of moving the mtn repo to hg, so this might happen very soon as well.<br>
<br>
HTH,<br><font color="#888888">
<br>
Ben<br>
<br>
</font></blockquote></div><br>