On 23 January 2014 23:54, Fraser Adams <fraser.ad...@blueyonder.co.uk>wrote:
> 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. > > Just to clarify things a little since much of this was before your (and to a smaller extent, even my own) time with the project, it was probably less that they became fragmented and more that they started that way. The Java broker initially had JMX based management functionality (as is/was popular for Java things to do) satisfying its model, and as the C++ broker developed it obviously needed managmement tooling to go with it, but didnt have the luxury of JMX built right into its runtime platform...though did have a nice AMQP interface sitting there, and so QMF grew to fill that need and beyond. Thus on the managemnet side things essentially started out different and then grew from there. In early 2010 we did add some initial support for QMF1 to the Java broker with aim of moving them closer together, but while we were still working on building that out the development on QMF itself moved away from an update of its existing binary protocol and instead toward creating what became the largely-new QMF2, making for a semi-start-over scenario. We didn't get round to that and the incomplete QMF1 support also withered over time, causing pain here and there due to continued enhancement of the C++ broker and the management schema then leading to breakages in the Java build. Given that many of the subsequent schema enhancements then werent implemented or simply couldnt be becuase they didnt fit the Java brokers model, be it due to the virtualhost disparity, protocol differences, or lower level things like the memory management, and in the end we removed the QMF1 support (or more accurately didnt bringing it along with us when we would have had to completely overhaul it to do so) at the time we begun to modularize the brokers management support out to plugins and started working on overhauling the configuration model toward its current form. Part of that change was us turning thoughts towards an embedded web management GUI to facilitate removing the Eclipse RCP based management console that existed previously, which then lead us to adding a REST API to power it (as has become a more popular way of managing things) which simply got based directly around the brokers new configuration model...and that about sums up how things ended up as they are now. As you later mention, we will be looking to add AMQP Management based functionality in time as that specification progresses. > 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/exchangewill > retrieve the exchanges > http://127.0.0.1:8080/qpid/connection/default/console/objects/connectionwill > 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 > >
