<div class="gmail_quote">I've spoken to Ben about this topic in the past, and he advised me to open an new topic on it, which is what I'm doing.<br><br>In the MQ world (IIRC) there is an administration API through which one can do virtually anything that one can do using the command runmqsc. I believe that RabbitMQ really, really needs something similar. When I could not figure out how to delete a no-longer needed permanent queue using rabbitmqctl, I wrote a simple Erlang module (source code attached), which I named rbmq_admin, that makes available a number of administrative RabbitMQ commands.<br>
<br>This exports the following Erlang functions:<br>
<br><span style="font-family: courier new,monospace;">stop/1, stop_app/1, start_app/1, reset/1, force_reset/1, cluster/2, status/1, add_user/3,</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">delete_user/2, change_password/3, list_users/1, add_vhost/2, delete_vhost/2, list_vhosts/1,</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">map_user_vhost/3, unmap_user_vhost/3, list_user_vhosts/2, list_vhost_users/2, add_realm/3,</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">delete_realm/3, list_realms/2, set_permissions/5, list_permissions/3, list_queues/1, delete_queue/3,</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">permission_list/1</span><br><br>With these, I can do just about anything I need to administer RabbitMQ. It uses rpc:call() to communicate with the Rabbit node, so it's usable across nodes, subject to Erlang features like cookies and -sname/-name usage. I use it to create realms, vhosts, users, and so on using Erlang. I even wrote a simple Yaws web page that lists all the queues on a given node and vhost, together with how many messages are outstanding on the queue and how many consumers are attached. With the wrapper, it's fairly trivial to do.<br>
<br>Now the weakness of this approach is that these commands are really just a thin wrapper over functions exported by the following RabbitMQ modules:<br><br><span style="font-family: courier new,monospace;">rabbit, rabbit_mnesia, rabbit_access_control, rabbit_realm, and rabbit_amqqueue.</span><br>
<br>This has the following shortcomings:<br><ol><li>It is intimately tied to rabbit internal APIs. Any change to the APIs, even just for the sake of refactoring, will break this.</li><li>It uses internal formats (e.g. tuples) returned by the API, which also tightly couples it to the internals.</li>
<li>It is non-standard.</li><li>It's only available in Erlang.</li></ol>For me, these are not huge issues right now (until they change the internals :). However, if there is to be a standard RabbitMQ Admin API, Ben and his colleagues will need to implement it and release it officially. We can help by defining what we would like to see in it.<br>
<br>What this topic hopes to achieve is to (a) gauge the interest in the RabbitMQ community for something like this, and (b) if there is enough interest, gather requirements -- or even just a wish list -- from the community. The wrapper I wrote and this post could be a starting point for this discussion.<br>
<br>The API would require at least the following:<br><ol><li>It would need to be available in multiple languages, to support the multiple clients (e.g. Java, .NET, Erlang). Hopefully it could be defined in such a way that one language-agnostic manual could be written for all the languages, together with short language-specific chapters to clarify exact usage for that language binding.<br>
</li><li>The formats of data passed to and returned from the API would have to become cast in concrete. For example, at the moment a list of queues returned by rabbit_amqqueue:stat_all/0 is in this format:<br>[<span style="font-family: courier new,monospace;">{ok,{resource,<<"resource name">>,queue,<<"queue name">>}, NumMsgs,NumConsumers},...]</span>. A canonical format for this (and all the others) needs to be defined, which won't change (or can change in a non-breaking way), even if there are internal RabbitMQ changes. Preferably, the data formats should be extensible so that new data points can easily be added that will not break existing code. How to do this across multiple languages is a good question, unless a language-agnostic format such as XML (heavy) or JSON (haven't used it) or something similar is used. I expect there will be much debate about this.<br>
</li><li>It would need to be powerful enough to do most or all administrative tasks. Again, the list of functions above could be a starting point.<br></li></ol>I hope this is of interest.<br><br>Regards,<br>Edwin Fine<br>
<br><div class="gmail_quote">On Wed, Jul 16, 2008 at 6:55 AM, Ben Hood <<a href="mailto:0x6e6562@gmail.com" target="_blank">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;">
Michael,<br>
<div><br>
On Wed, Jul 16, 2008 at 10:44 AM, Tony Garnock-Jones <<a href="mailto:tonyg@lshift.net" target="_blank">tonyg@lshift.net</a>> wrote:<br>
> Hi Michael,<br>
><br>
> Michael Arnoldus wrote:<br>
>> Speaking of which - if it should happen that I one late night are<br>
>> finding myself sorely missing working in erlang to the degree that I'd<br>
>> like to experiment with this - do you have any docs or just pointers to<br>
>> how to receive and send AMQP from inside erlang? I guess using the<br>
>> erlang AMQP client to let the server talk to itself isn't exactly the<br>
>> right approach ...<br>
<br>
</div>Can you elaborate on why using the Erlang client to let the *server<br>
speak to itself* may the wrong approach?<br>
<br>
As Tony has pointed out in the previous post, you can use the internal<br>
rabbit API to send and receive messages, but this means that you tie<br>
yourself in the internals of Rabbit, which *may* change over time.<br>
<br>
HTH,<br>
<font color="#888888"><br>
Ben<br>
</font><div><div></div><div><br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)
</div><br><br clear="all"><br>-- <br>The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought.<br>
John F. Kennedy 35th president of US 1961-1963 (1917 - 1963)