<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Ed,<div><br><div><div>On 10 May 2008, at 01:02, Edwin Fine wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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></blockquote></div><br></div><div>Sorry for not responding to this sooner, the offer is appreciated. Having said that, part of the functionality you have written is a wrapper around the rabbit_access_control module, which is pretty much what the rabbit_control module is (see the rabbitmqctl script). That's not to say there is no merit in improving the whole management aspect of RabbitMQ, which I think is the important point you making with the rbmq_admin module you have written. I know there have been a few posts about the reshaping the current management facilities, but (although I may stand corrected) these discussions have been more along the lines of requirements gathering and getting users to say what types of management functionality they'd like to see in the product. Hence your module can definitely serve as a description of what you'd like to see. In the past I have expressed some views about the remoting aspect of rabbit management, but what you are touching on is the core services that are offered. Obviously these will need to discussed in order to come up with a stable API that isn't so tightly coupled to the implementation aspects of the server, which *will* change over time. To generate interest in this, I suggest you start a new discussion topic on this.</div><div><br></div><div>On the other side of things, I have done some further refactoring to the writer cleanup and concurrency of RPC requests, so if you did get an opportunity to give your code a go using the single channel variant with basic consume, that would be greatly appreciated.</div><div><br></div><div>HTH, </div><div><br></div><div>Ben</div></body></html>