Return-Path: 
 <users-return-10214-apmail-qpid-users-archive=qpid.apache.org@qpid.apache.org>
X-Original-To: apmail-qpid-users-archive@www.apache.org
Delivered-To: apmail-qpid-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E1D1010933
	for <apmail-qpid-users-archive@www.apache.org>;
 Thu, 13 Mar 2014 17:51:21 +0000 (UTC)
Received: (qmail 13082 invoked by uid 500); 13 Mar 2014 17:51:21 -0000
Delivered-To: apmail-qpid-users-archive@qpid.apache.org
Received: (qmail 12684 invoked by uid 500); 13 Mar 2014 17:51:19 -0000
Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@qpid.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@qpid.apache.org>
List-Post: <mailto:users@qpid.apache.org>
List-Id: <users.qpid.apache.org>
Reply-To: users@qpid.apache.org
Delivered-To: mailing list users@qpid.apache.org
Received: (qmail 12666 invoked by uid 99); 13 Mar 2014 17:51:17 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Mar 2014 17:51:17 +0000
X-ASF-Spam-Status: No, hits=0.0 required=5.0
	tests=NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_NONE,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of fraser.adams@blueyonder.co.uk
 designates 80.0.253.75 as permitted sender)
Received: from [80.0.253.75] (HELO
 know-smtprelay-omc-11.server.virginmedia.net) (80.0.253.75)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Mar 2014 17:51:10 +0000
Received: from [192.168.1.108] ([82.38.120.72])
	by know-smtprelay-11-imp with bizsmtp
	id d5qo1n0251Zorai015qoXU; Thu, 13 Mar 2014 17:50:49 +0000
X-Originating-IP: [82.38.120.72]
X-Spam: 0
X-Authority: v=2.1 cv=RqlLLUWK c=1 sm=1 tr=0 a=kn84lg4yEBBc+Mp7+mj2YQ==:117
 a=kn84lg4yEBBc+Mp7+mj2YQ==:17 a=thNyya010k0A:10 a=TO_-2BeFaa8A:10
 a=3NElcqgl2aoA:10 a=a5Gf7U6LAAAA:8 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10
 a=cKsnjEOsciEA:10 a=BKekG--sAAAA:8 a=20KFwNOVAAAA:8 a=mV9VRH-2AAAA:8
 a=4NAF5AE4AAAA:8 a=3NJyOidealHSysymmaEA:9 a=o-Be5_Z2hTkERkoJ:21
 a=-rNmdfC_7pzUtlUt:21 a=wPNLvfGTeEIA:10 a=jEp0ucaQiEUA:10 a=LRLYrf9nAAAA:8
 a=JjoxDxyBAAAA:8 a=e1pcYkvab4hi-xJg5qkA:9 a=WJkbv6Bpw4gA:10 a=09KH9ivod7IA:10
 a=qiWi7Edwir4A:10 a=NWVoK91CQyQA:10 a=YRA9smCCCpM1NFNi8s8A:9
 a=nzKBlXNHQnsNTZ39:21 a=1nPTF_FJdrr2NhHj:21 a=QEXdDO2ut3YA:10
 a=yHIqe9kG5mgA:10 a=GDSD-zdpX0G609ztIJwA:9 a=owmGRbpJLYghvVlz:21
 a=vfOSrrZ_58fE8HjO:21 a=eZxP2M26cf0Z3xWgOTsA:9 a=zlFeGdpSxXV8BBVA:21
 a=teHymDU-M4Uv9tBN:21
Message-ID: <5321EFF8.2020206@blueyonder.co.uk>
Date: Thu, 13 Mar 2014 17:50:48 +0000
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: Send messages from one queue to another queue?
References: 
 <5BDF75D02AC1DB4C9DF96C0D0EB948BAABA3AAEA@PDCEXC001.prague.wood.cz>
 <53208310.2030405@redhat.com>
 <5BDF75D02AC1DB4C9DF96C0D0EB948BAABA3AF78@PDCEXC001.prague.wood.cz>
 <53218F60.4000501@redhat.com>
 <5BDF75D02AC1DB4C9DF96C0D0EB948BAABA3AFD5@PDCEXC001.prague.wood.cz>
In-Reply-To: 
 <5BDF75D02AC1DB4C9DF96C0D0EB948BAABA3AFD5@PDCEXC001.prague.wood.cz>
Content-Type: multipart/mixed;
 boundary="------------050308040908010902040008"
X-Virus-Checked: Checked by ClamAV on apache.org

--------------050308040908010902040008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Don't know if you noticed my post yesterday about the move/purge/reroute 
stuff being available via the QMF GUI?

Gordon beat me to the main source of documentation, which is the 
management-schema.xml though unfortunately that *may* not necessarily be 
enough to do anything useful - most of the QMF methods take Maps of 
properties as formal parameters so the CRUD <type> <name> stuff is 
probably obvious but the remaining information that's generally needed 
much less so.

As an example the properties usually needed when say creating a queue or 
information relating to the filter when moving/rerouting messages.

You've never said in your posts what language you are most interested 
in. We've provided some hopefully useful responses to you, but your 
original question was asking "I would like to use something like Zabbix 
(www.zabbix.com) for QPID monitoring" now I think that the QMF GUI et. 
al. are pretty good, but they are serving a different purpose than the 
one implied by this original question so I'm thinking that to interface 
with Zabbix (which I know nothing about) you are going to have to write 
your own QMF console application and how you go about that will vary 
depending on your language of preference (whatever plugs best into 
Zabbix I presume).

With Python or Java things are fairly simple I'd say that your best bet 
would be to look at the python qpid-config or the Java port QpidConfig 
the getObjects call is likely to be your friend - queueListRecurse and 
exchangeListRecurse in those shows the more common use cases and my 
ConnectionAudit shows how do do some slightly fancier things.

If you have to write a C++ client it's a little harder, there you 
generally have to write QMF protocol Map Messages directly although as 
it happens the QMF GUI is backed by a REST API (QpidRestAPI which you've 
already come across) and you can do everything via REST. I've attached a 
couple of emails that I put out onto the list to help out Davin Shearer 
a few weeks back (I really need to add that stuff to the README) 
hopefully that will help you out - it illustrates quite a lot of 
low-level QMF method invocation and I suspect contains more detail than 
anything else. The second attached mail also contains a couple of 
examples from Gordon on how to prod the QMF protocol natively from C++.


I have to add the usual caveat that Qpid Management is likely to start 
undergoing a period of flux. For AMQP 1.0 there is a Management Protocol 
that is currently under work (updates get regularly posted to the user 
list). It has a number of similarities to QMF, but equally is somewhat 
different. I've spent some time looking at it but I've not yet had time 
to properly sit down and work out what it means from the perspective of 
"how the heck to we *migrate*" Management tooling. I don't there's an 
identified strategy yet around whether we try to be clever and have 
tools that can work with either QMF or AMQP 1.0 Management or whether we 
"clone" the existing tools with the same user API and features but 
different implementations. It's probably too early to call on that at 
the moment, but I always feel compelled to mention that this is on the 
horizon because if you are building a mission critical system you're 
going to want to make sure that you mention this in your documentation 
around monitoring and make sure that you (or someone) maintain a 
watching brief as things evolve.

I really wouldn't want to put you off, but knowledge of this will 
probably have implications for your design choices and general due 
diligence.

Best regards,
Frase


On 13/03/14 12:08, Jan Bares wrote:
> Thanks Gordon, that is exactly what I was looking for.
>
> Kind regards, Jan
>
>> -----Original Message-----
>> From: Gordon Sim [mailto:gsim@redhat.com]
>> Sent: Thursday, March 13, 2014 11:59 AM
>> To: users@qpid.apache.org
>> Subject: Re: Send messages from one queue to another queue?
>>
>> On 03/13/2014 10:43 AM, Jan Bares wrote:
>>> Yes, this is C++ broker. I am curious where to find list of QMF commands
>> and parameters but did not found anything. Where are they documented?
>>
>> Unfortunately all there is is the schema 'document' itself, which is now
>> in
>> https://svn.apache.org/repos/asf/qpid/trunk/qpid/cpp/src/qpid/broker/ma
>> nagement-schema.xml
>>
>> You can also query it using qpid-tool: type schema or schema <class>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>
>
>
> DISCLAIMER
> ________________________________
>           WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Slovakia by the NBS and in the UK by the FCA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.com<http://www.wood.com/> under section Corporate Governance.
>           Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
>           This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
> ________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>


--------------050308040908010902040008
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message"

Message-ID: <52E1ABA3.9070504@blueyonder.co.uk>
Date: Thu, 23 Jan 2014 23:54:11 +0000
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: QMF REST API - was Re: How to use lifetime policies
References: 
 <CAO+6tXGO=SobeUWcFTGK=gi_rzzSJRW+1ugvPeLFV=-WWX78+g@mail.gmail.com>
 <52CFBA21.7050902@blueyonder.co.uk> <52CFEF41.3040905@redhat.com>
 <CAO+6tXHj6uYup+C2dmu9W44WgpctfAe5+q05j8MZ6Lm23GRZ8A@mail.gmail.com>
 <52D02514.7060501@redhat.com>
 <CAO+6tXGEkcto2S-KCCCd=035bTKRWifOo7mim6Dvf+fDSDfD9Q@mail.gmail.com>
 <52D05C2D.9070204@blueyonder.co.uk>
 <C8F22BC5-59EB-4018-AD75-C3F642E290ED@novetta.com>
 <52D15693.1080402@blueyonder.co.uk>
 <CAO+6tXHBWKCBG-gVLPH9bi3dXXbNT1HUVWAiKopw0ojCbSncZA@mail.gmail.com>
 <52D7A554.6050806@blueyonder.co.uk>
 <CAO+6tXEFNqYOSkOD1ae4Q=QvPUmHSVy3=9sMkDqefNfDQ8mUfw@mail.gmail.com>
 <52D8FCB4.5070702@redhat.com> <52D92155.60604@blueyonder.co.uk>
 <CAO+6tXFCO1YZs91JcEWvhMGtfnP=d_qyiYjC+4nU9J8PQkA8OA@mail.gmail.com>
 <52D984E8.3090405@blueyonder.co.uk>
 <CAO+6tXHudN3-1w+ekQaV5kJb6c-6WVYa_ZZpsV5vFVBN7erXSw@mail.gmail.com>
 <CAFitrpQ2ROmbW5A619FGC87wGXbC3Jq51iipBOZynMJ_rgLPGw@mail.gmail.com>
In-Reply-To: 
 <CAFitrpQ2ROmbW5A619FGC87wGXbC3Jq51iipBOZynMJ_rgLPGw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 <dshearer@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
>


--------------050308040908010902040008
Content-Type: message/rfc822;
 name="Attached Message"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message"

Message-ID: <52E7F972.8000606@blueyonder.co.uk>
Date: Tue, 28 Jan 2014 18:39:46 +0000
From: Fraser Adams <fraser.adams@blueyonder.co.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: users@qpid.apache.org
Subject: Re: QMF REST API - was Re: How to use lifetime policies
References: 
 <CAO+6tXGO=SobeUWcFTGK=gi_rzzSJRW+1ugvPeLFV=-WWX78+g@mail.gmail.com>
 <52CFEF41.3040905@redhat.com>
 <CAO+6tXHj6uYup+C2dmu9W44WgpctfAe5+q05j8MZ6Lm23GRZ8A@mail.gmail.com>
 <52D02514.7060501@redhat.com>
 <CAO+6tXGEkcto2S-KCCCd=035bTKRWifOo7mim6Dvf+fDSDfD9Q@mail.gmail.com>
 <52D05C2D.9070204@blueyonder.co.uk>
 <C8F22BC5-59EB-4018-AD75-C3F642E290ED@novetta.com>
 <52D15693.1080402@blueyonder.co.uk>
 <CAO+6tXHBWKCBG-gVLPH9bi3dXXbNT1HUVWAiKopw0ojCbSncZA@mail.gmail.com>
 <52D7A554.6050806@blueyonder.co.uk>
 <CAO+6tXEFNqYOSkOD1ae4Q=QvPUmHSVy3=9sMkDqefNfDQ8mUfw@mail.gmail.com>
 <52D8FCB4.5070702@redhat.com> <52D92155.60604@blueyonder.co.uk>
 <CAO+6tXFCO1YZs91JcEWvhMGtfnP=d_qyiYjC+4nU9J8PQkA8OA@mail.gmail.com>
 <52D984E8.3090405@blueyonder.co.uk>
 <CAO+6tXHudN3-1w+ekQaV5kJb6c-6WVYa_ZZpsV5vFVBN7erXSw@mail.gmail.com>
 <CAFitrpQ2ROmbW5A619FGC87wGXbC3Jq51iipBOZynMJ_rgLPGw@mail.gmail.com>
 <52E1ABA3.9070504@blueyonder.co.uk>
 <CAO+6tXEOw3ixUh21aRi2xN8BTmZisdb9EwAtwPHNbjWKScnwDA@mail.gmail.com>
In-Reply-To: 
 <CAO+6tXEOw3ixUh21aRi2xN8BTmZisdb9EwAtwPHNbjWKScnwDA@mail.gmail.com>
Content-Type: multipart/mixed;
 boundary="------------040305090705040706050008"

This is a multi-part message in MIME format.
--------------040305090705040706050008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Glad that I was able to help out.
I'm a little bit curious why you're choosing to go with the REST 
interface directly? What language are you programming in.

Not that I've got anything against the REST API, but I mainly put it in 
place to be able to talk QMF from a browser environment.

If you are programming in Java you'd probably find it easier to use the 
Java QMF API directly, if you're doing python then use the API that 
qpid-config etc. use, from C++ it's a little more awkward but not too 
hard to send QMF2 protocol requests out (it's ultimately just a bunch of 
Map Messages) I've attached a couple of examples put together by Gordon 
Sim to illustrate this in C++ the queue_depth is self explanatory, the 
one marked example.cpp does something similar to qpid-route - not 
exactly what you want for adding a queue, but it illustrates invoking 
QMF2 methods via the raw QMF2 protocol and you can use that in 
conjunction with what I've shown below on the REST API (this bit

{
"_method_name":"create",
"_arguments": {"type": "queue", "name": "davin_test2", "properties":
{"durable": true}}
}

)

It is quite fun doing this stuff via curl, but it's pretty hardcore :-) 
I'd *probably* take easier options in Python/Java/C++/JavaScript unless 
I wanted to prove a point (clearly REST is handy if you want to mash up 
info from lots of different sources in a web app).

BTW in case you are curious the reason that the URI's are relatively 
complex e.g.
GET http://127.0.0.1:8080/qpid/connection/default/console/objects/queue 
rather than say
GET http://127.0.0.1:8080/qpid/console/objects/queue

Is because it's perfectly possible to PUT an arbitrary number of QMF 
Console connections and access them independently so the GUI can talk to 
multiple discrete Consoles and I can have multiple browser instances 
served by the same REST API instance.

Cheers,
Frase

On 27/01/14 22:06, Shearer, Davin wrote:
> Thanks Frase,
>
> I read and followed along through your explanation and was able to browse
> various objects and finally create a queue via the REST API backed by the
> C++ broker using only curl (yay!).  Hopefully I can use the interface to
> create one dynamically with the delete on close attribute.  I'll give that
> a go tomorrow!
>
>
> On Thu, Jan 23, 2014 at 6:54 PM, Fraser Adams <fraser.adams@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.
>>
>> 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 <dshearer@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-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>


--------------040305090705040706050008
Content-Type: text/x-c++src;
 name="queue_depth.cpp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="queue_depth.cpp"

/*
 *
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 *
 */


#include <qpid/messaging/Address.h>
#include <qpid/messaging/Connection.h>
#include <qpid/messaging/Message.h>
#include <qpid/messaging/Receiver.h>
#include <qpid/messaging/Sender.h>
#include <qpid/messaging/Session.h>
#include <qpid/types/Variant.h>
#include <iostream>

using namespace qpid::messaging;
using namespace qpid::types;

using std::string;

int main(int argc, char** argv)
{
    if (argc == 1) {
        std::cout << "Please specify a queue name." << std::endl;
        return 1;
    }
    std::string queue(argv[1]);
    Connection c(argc > 2 ? argv[2] : "localhost");
    try {
        c.open();
        Session session = c.createSession();
        Address responses("#; {create: always, node: {x-declare: {auto-delete:True}}}");
        Receiver r = session.createReceiver(responses);
        Sender s = session.createSender("qmf.default.direct/broker");

    	Message request;
        request.setReplyTo(responses);
        request.setContentType("amqp/map");
        request.setProperty("x-amqp-0-10.app-id", "qmf2");
        request.setProperty("qmf.opcode", "_query_request");
        Variant::Map oid;
        oid["_object_name"] = std::string("org.apache.qpid.broker:queue:") + queue;
        Variant::Map content;
        content["_what"] = "OBJECT";
        content["_object_id"] = oid;

        encode(content, request);
        s.send(request);
        Message response = r.fetch();
        Variant::List contentIn;
        decode(response, contentIn);
        if (contentIn.size() == 1) {
            Variant::Map details = contentIn.front().asMap()["_values"].asMap();
            std::cout << "Message depth for " << queue << " is " << details["msgDepth"] << std::endl;
        } else if (contentIn.size() == 0) {
            std::cout << "No such queue: "  << queue << std::endl;
        } else {
            std::cout << "Unexpected number of entries: "  << contentIn << std::endl;
        }
        session.acknowledge();
    } catch(const std::exception& error) {
        std::cout << "ERROR: " << error.what() << std::endl;
    }
    c.close();
    return 0;
}




--------------040305090705040706050008
Content-Type: text/x-c++src;
 name="example.cpp"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="example.cpp"

/*
 *
 * Licensed to the Apache Software Foundation (ASF) under one
 * or more contributor license agreements.  See the NOTICE file
 * distributed with this work for additional information
 * regarding copyright ownership.  The ASF licenses this file
 * to you under the Apache License, Version 2.0 (the
 * "License"); you may not use this file except in compliance
 * with the License.  You may obtain a copy of the License at
 *
 *   http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing,
 * software distributed under the License is distributed on an
 * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
 * KIND, either express or implied.  See the License for the
 * specific language governing permissions and limitations
 * under the License.
 *
 */


#include <qpid/messaging/Address.h>
#include <qpid/messaging/Connection.h>
#include <qpid/messaging/Message.h>
#include <qpid/messaging/Receiver.h>
#include <qpid/messaging/Sender.h>
#include <qpid/messaging/Session.h>
#include <qpid/types/Variant.h>
#include <iostream>
#include <sstream>

using namespace qpid::messaging;
using namespace qpid::types;

using std::string;

class Controller
{
  public:
    Controller(Session&);
    void link(const std::string& name, const std::string& host, uint16_t port,
              const std::string& transport=std::string(), const std::string& mechanisms=std::string(),
              const std::string& username=std::string(), const std::string& password=std::string());
    void bridge(const std::string& name, const std::string& link,
                const std::string& src, const std::string& dest, const std::string& tag=std::string());
  private:
    Address replyTo;
    Sender sender;
    Receiver receiver;

    void invoke(const std::string& method, const Variant::Map& args);
};

int main(int argc, char** argv)
{
    Connection c(argc > 1 ? argv[1] : "localhost");
    try {
        c.open();
        Session session = c.createSession();
        Controller controller(session);
        controller.link("my-link", "localhost", 5673);
        controller.bridge("my-bridge", "my-link", "amq.fanout", "amq.fanout");
    } catch(const std::exception& error) {
        std::cout << "ERROR: " << error.what() << std::endl;
    }
    c.close();
    return 0;
}

Controller::Controller(Session& session) :replyTo("#; {create:always, node:{x-declare:{auto-delete:true}}}"),
                                          sender(session.createSender("qmf.default.direct/broker")),
                                          receiver(session.createReceiver(replyTo)) {}

void Controller::link(const std::string& name, const std::string& host, uint16_t port, const std::string& transport, const std::string& mechanism, const std::string& username, const std::string& password)
{
    Variant::Map args;
    args["type"] = "link";
    args["name"] = name;
    Variant::Map props;
    props["host"] = host;
    props["port"] = port;
    if (!transport.empty()) props["transport"] = transport;
    if (!mechanism.empty()) props["authMechanism"] = mechanism;
    if (!username.empty()) props["username"] = username;
    if (!password.empty())props["password"] = password;
    args["properties"] = props;
    invoke("create", args);
}

void Controller::bridge(const std::string& name, const std::string& link,
                        const std::string& src, const std::string& dest, const std::string& tag)
{
    Variant::Map args;
    args["type"] = "bridge";
    args["name"] = name;
    Variant::Map props;
    props["link"] = link;
    props["src"] = src;
    props["dest"] = dest;
    if (!tag.empty()) props["tag"] = tag;
    args["properties"] = props;
    invoke("create", args);
}

void Controller::invoke(const std::string& method, const Variant::Map& args)
{
    Variant::Map content;
    Variant::Map objectId;
    objectId["_object_name"] = "org.apache.qpid.broker:broker:amqp-broker";
    content["_object_id"] = objectId;
    content["_method_name"] = method;
    content["_arguments"] = args;

    Message request;
    request.setReplyTo(replyTo);
    request.getProperties()["x-amqp-0-10.app-id"] = "qmf2";
    request.getProperties()["qmf.opcode"] = "_method_request";
    encode(content, request);

    sender.send(request);

    Message response;
    if (receiver.fetch(response, Duration::SECOND*5)) {
        if (response.getProperties()["x-amqp-0-10.app-id"] == "qmf2") {
            std::string opcode = response.getProperties()["qmf.opcode"];
            if (opcode == "_exception") {
                Variant::Map m;
                decode(response, m);
                std::cout << "Error: " << m["_values"] << std::endl;
            }
        } else {
            std::cout << "Invalid response received, not a qmfv2 message: app-id="
                      << response.getProperties()["x-amqp-0-10.app-id"] << std::endl;
        }
    } else {
        std::cout << "No response received" << std::endl;
    }
}

--------------040305090705040706050008--


--------------050308040908010902040008
Content-Type: text/plain; charset=us-ascii


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
--------------050308040908010902040008--