[rabbitmq-discuss] [New project] amqp-utils, CLI utilities for AMQP queues

Jason J. W. Williams jasonjwwilliams at gmail.com
Sat Feb 7 19:32:17 GMT 2009

Hi Alexis,

Actually just played with it yesterday at dev.rabbitmq.com for the
first time. Need to spend more time with it, but it looks promising.
Trying to figure a way around RMQ cluster blackholing messages on
failover atm.


On 2/7/09, Alexis Richardson <alexis.richardson at cohesiveft.com> wrote:
> Jason,
> Have you looked at how Tony's JSON-RPC over AMQP over HTTP works?  The
> code is in the HTTP libs in the repo, IIRC.
> alexis
> On Fri, Feb 6, 2009 at 6:55 PM, Jason J. W. Williams
> <jasonjwwilliams at gmail.com> wrote:
>> Personally, I'd like to see it exposed over AMQP using queues with
>> chosen reserved names. Exposing it over JSON would be great, but I
>> think if we're already using AMQP to access it, it should be pretty
>> easy to build a web GUI that uses AMQP to get the answers.
>> -J
>> On Fri, Feb 6, 2009 at 8:46 AM, Alexis Richardson
>> <alexis.richardson at cohesiveft.com> wrote:
>>> Valentino,
>>> Thanks, that is a very useful contribution.  I'll ask Tony how hard it
>>> would be to expose this using his JSON stuff.
>>> alexis
>>> On Thu, Feb 5, 2009 at 9:55 AM, Valentino Volonghi <dialtone at gmail.com>
>>> wrote:
>>>> Hash: SHA1
>>>> On Feb 5, 2009, at 1:35 AM, Alexis Richardson wrote:
>>>>> Thanks for the feedback on this.
>>>>> As Valentino and Al point out, keeping things compact is important,
>>>>> and not all users are running or want to run a web framework with
>>>>> RabbitMQ.  Though of course some will.
>>>>> So one option here is to use the built-in HTTP capability rather than
>>>>> a web framework.  For example, to provide an interface to rabbitmqctl
>>>>> that lets people use a browser to keep an eye on the broker.
>>>>> On the other hand people may prefer programmatic management.
>>>> I'm pretty sure that with an HTTP server built-in you can do anything
>>>> to rabbitmq, even writing consumers in javascript :).
>>>> More seriously:
>>>> An HTTP server that exposes some kind of simple REST API that
>>>> can be queries also from javascript would mean that even a static
>>>> page (hardly a match for a built-in http server) could be served
>>>> efficiently and act as a monitoring screen.
>>>> As for the REST API I'm thinking along the lines of:
>>>> /stats/ <- general stats and list of exchanges
>>>> /stats/<EXCHANGE>/ <- list of queues under exchange
>>>> /stats/<EXCHANGE>/<QUEUE>/ <- queue stats
>>>> /stats/users/
>>>> /stats/consumers/
>>>> /stats/acls/
>>>> ...
>>>> simple http-auth is more than enough if you really want to make
>>>> this secure and could use the same users credentials that rabbitmq
>>>> stores for the rest of the system. And the response format for each
>>>> request would simply be JSON, then a single html page can be
>>>> used to show all the stats that one might need. This has no memory
>>>> overhead because everything is done on the client side and can be
>>>> freely extended by simply changing javascript without the need to
>>>> deploy a new web server somewhere (etc etc).
>>>> Then by quering (polling at the beginning, comet when there's more
>>>> time to develop something like this) a url multiple times one can build
>>>> a chart of the stats (and if polling the built-in http server doesn't
>>>> even
>>>> need to know that it is happening).
>>>> - --
>>>> Valentino Volonghi aka Dialtone
>>>> Now running MacOS X 10.5
>>>> Home Page: http://www.twisted.it
>>>> http://www.adroll.com
>>>> -----BEGIN PGP SIGNATURE-----
>>>> Version: GnuPG v1.4.9 (Darwin)
>>>> pzwAnRlrN8uI6BS7vTEHKgOLFOzj1Lqd
>>>> =7ifr
>>>> -----END PGP SIGNATURE-----
>>> _______________________________________________
>>> rabbitmq-discuss mailing list
>>> rabbitmq-discuss at lists.rabbitmq.com
>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

More information about the rabbitmq-discuss mailing list