Hey Davin,
Robbie has hit the nail on the head. One somewhat unfortunate thing that
you probably ought to be aware of is that the management and monitoring
for the Qpid C++ and Java Brokers got somewhat erm "fragmented" for
various reasons back in the mists of time.
The C++ Broker uses Qpid Management Framework (QMF), but that has had an
interesting evolution and at some point in history QMFv1 migrated to
QMFv2 which caused issues for the Java Broker and they ended up going
down a different path.
I primarily use the C++ broker, but conversely my team mainly use Java,
so I started out doing a Java implementation of the QMF2 API without
knowing much of that background. There was a bit of comedy 'cause the
Qpid Java guys didn't take a lot of notice of what I was doing 'cause it
was QMF and the C++ guys didn't really notice 'cause it was Java :-D I
was a bit in no mans land really :-/
It wasn't really until I put the GUI together that anyone really noticed
and the penny dropped.
So as Robbie says the REST API that I put together is *actually* a REST
binding for QMF2 and (apart from being a REST API) doesn't bear too much
relationship to the Java Broker's REST interface (for most of history we
were largely unaware of what each other was up to).
It's a far from ideal position and Rob, Gordon, Robbie and I have
chatted a fair bit about the need to get a more cohesive view.
Ultimately the right answer will be to adopt the AMQP Management
Specification across the board, though that's likely to be some way off
(I certainly need to find some time to properly get my head around it).
By way of "making a stand for the unity of Qpid Brokers :-)" I put
together a QMF2 plugin for the Java Broker, it was one of those things
that one does "on principle" - really it was as much as anything a
statement to say "really guys it *is* actually possible to provide a
cohesive view". One thing to bear in mind with the Java Broker QMF
plugin is that I've tried fairly hard to map as much as possible from
the Java Broker internal Management Model to QMF Management Objects, but
there are differences in the Management Models, so there are certainly
more itty bitty things that can be controlled by the Java Broker's
native management interface than via QMF (mainly 'cause Robbie keeps
adding features ;->) but OTOH pretty much anything you can do with
qpid-config will work with both the C++ and Java Brokers.
So to get back to the QMF REST API, the best place to look is the
JavaDoc (yes really, there is actually a ton of JavaDoc for this stuff)
start in <qpid>/tools/src/java/docs/api/index.html
Then look for package org.apache.qpid.restapi and class QpidServer
To get you started if you do (assuming the same host and port as below):
http://127.0.0.1:8080/qpid/connection/default/console/objects/queue
You will retrieve a list of all of the QMF Queue Management Objects in
the form of a JSON list (you can do it in a browser too)
http://127.0.0.1:8080/qpid/connection/default/console/objects/exchange
will retrieve the exchanges
http://127.0.0.1:8080/qpid/connection/default/console/objects/connection
will retrieve the connections
and so on.
the <default> bit is a "convenience", so this is a "true" REST API that
mirrors the QMF API pretty closely so you really ought to first PUT a
QMF Console Connection before you do anything else, but of course PUT is
a pain from a browser, so if you specify "default" for the connection
part of the URI the API transparently creates (or uses an already
created) default QMF Console instance.
The GUI actually has a JavaScript class that provides a JavaScript
implementation of the QMF2 API, which is backed by the REST API, so the
GUI is generally abstracted from the REST API, there's a factory method
for that which does the HTTP PUT "under the hood"
You can also use POST in order to invoke QMF methods (for
adding/deleting queues etc.).
To be honest I'm a bit rusty - I tend to use the GUI or at worse the
JavaScript wrapper which abstracts the detail,
and I've not done it "the hard way" for the best part of 15 months, so
the following is pulled out from the code.
The POST syntax is:
POST: <host>:<port>/qpid/connection/<name>/object/<ObjectId>
HTTP body: {"_method_name":<method>,"_arguments":<inArgs>}
<method>: A string containing the QMF2 method name e.g. "getLogLevel", "setLogLevel",
"create", "delete".
<inArgs>: A JSON string containing the method arguments e.g.
{"level":"debug+:Broker"} for setLogLevel.
HTTP response: A JSON string containing the response e.g.
{"level":"notice+"} for getLogLevel (may be empty).
This method invokes the QMF2 method <method> with arguments <inArgs> on the
object <ObjectId>
And it works like QMF, so what you'd first need to do is to recover the Broker
Management Object
http://127.0.0.1:8080/qpid/connection/default/console/objects/broker
You need to do this because the majority of the QMF CRUD methods are applied on
the Broker Management Object,
having done this you'd need to do a POST as above (using the ObjectId from your
own Broker Object)
POST
http://127.0.0.1:8080/qpid/connection/default/object/@0...@org.apache.qpid.broker:broker:amqp-broker
And in the HTTP body you need a JSON string.
To Add a queue I *think* that the JSON body goes something like this (for your
davin_test2 queue):
{
"_method_name":"create",
"_arguments": {"type": "queue", "name": "davin_test2", "properties":
{"durable": true}}
}
Clearly this isn't something that one would *generally* do "by hand".
I've just done:
curl -X POST -u admin:admin -d '{"_method_name":"create","_arguments": {"type": "queue", "name":
"davin_test2", "properties": {"durable": true}}}'
http://127.0.0.1:8080/qpid/connection/default/object/@0...@org.apache.qpid.broker:broker:amqp-broker
On my system and it created a queue called "davin_test2", so I think what I've
just said is accurate, yay!!
The available properties for Queues and exchanges isn't brilliantly documented
in the QMF Management Schema
(or anywhere really) and I kind of "reverse engineered" them, looking through
the GUI code (qmf-ui.js in qmfui.AddQueue method)
I can see:
qpid.max_size
qpid.max_count
qpid.flow_stop_size
qpid.flow_stop_count
qpid.flow_resume_size
qpid.flow_resume_count
durable
qpid.file_size
qpid.file_count
qpid.policy_type
qpid.last_value_queue
qpid.last_value_queue_no_browse
qpid.queue_event_generation
alternate-exchange
If you look in the qpid-config code I think you'd come across these too.
I've *probably* just made your head explode, so I'd better stop there,
*hopefully* this is helpful and useful background.
Best regards,
Frase
P.S. Glad that you like the QMF GUI - it looks pretty nice on an iOS device, it
uses CSS3 animations so the transitions are GPU accelerated.
On 23/01/14 19:42, Robbie Gemmell wrote:
On 23 January 2014 19:27, Shearer, Davin <dshea...@novetta.com> wrote:
[davin@laptop24 qpid]$ curl -X GET -u admin:admin
http://127.0.0.1:8080/rest/queue/davin_test
404 Not Found: File /rest/queue/davin_test not found.[davin@laptop24qpid]$
Darn, that didn't work... can we put new queues?
[davin@laptop24 qpid]$ curl -X PUT -u admin:admin -d '{"durable":true}'
http://127.0.0.1:8080/rest/queue/default/davin_test2
405 Bad Method.[davin@laptop24 qpid]$
What am I missing?
Those URLs look a lot like ones that would be used against the REST API
from the Java brokers management-http plugin. The URLs/payloads used by the
'QMF REST API' from the tools Fraser put together aren't likely to be that
similar to them.
I'll now have to defer to someone who can tell you what they would be
like...
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
