qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: Questions from a novice
Date Mon, 01 Apr 2013 18:12:59 GMT
Firstly to say that I'm currently on holiday under a qpid curfew :-) so I can only sneak in
a quick response at the moment, I'll try to give some proper answers to questions posed in
this thread later on in the week.

On Gordon's --mgmt-qmf1=false I "thought" those broker flags only actually related to "push"
messages sent from the broker, so that"s things like heartbeats and the broker "data push"
that can be subscribed to, I'm pretty sure that the request/response stuff is driven by the
address used, for example qmf2 uses qmf.default.direct or qmf.default.topic, for qmf1 there's
another address qpid.management??? - I'd need to check. Anyway I think that's how you'd select
between QMF2 and QMF1 for request response type things. The python APIs do this transparently
under the hood.

there's been some talk about ObjectIds, now it is true to say that V2 ObjectIds comprise a
Map that may have some meaningful names, but the qmf2 API spec says that they are supposed
to be opaque, the python lib tools have definitely "interpreted" them, but I'm not personally
convinced that that's a great idea. I've certainly avoided interpreting them in anything I've
done with QMF. To be fair it is all a bit ambiguous give that the names in the protocol suggest
something, but as I say the QMF2 API doc definitely says opaque, but then again the API seems
to have fallen against the wayside rather, which is kind of a shame.

One comment for Bill, the GUI that I put together has been mentioned, it's worth taking a
look at, in particular it's not just a GUI, it's backed by a Java implementation of the documented
QMF API, so if your Web server is Java based that might be more convenient to use that a python
API. There is also a Rest API for QMF and a JavaScript API that is backed by the Rest API.

One last thing, there is some discussion beginning about the future of management, the eventual
intention is to move away from QMF towards a new AMQP management API, however that is in the
very early stages so at the moment QMF is the only game in town for C++ broker management.
There are a few of us very keen to make sure that transition to the new API is as painless
as possible, but as I say it's very very early days and is mainly said to try to ensure that
you bear it in mind with your application. I'd very definitely avoid QMF1 though QMF2 is a
better bet.

I'll try to give some slightly deeper responses later in the week,

On 1 Apr 2013, at 18:35, Bill Freeman <ke1g.nh@gmail.com> wrote:

> On Mon, Apr 1, 2013 at 12:21 PM, Gordon Sim <gsim@redhat.com> wrote:
>> On 04/01/2013 05:06 PM, Bill Freeman wrote:
>>> since I have a dog and pony show coming up shortly, do you
>>> know how to get the existing qmf.console stuff to send my updates as V2
>>> (session has rcvObjects True).
>> One option might be to turn v1 off at the broker... --mgmt-qmf1=false to
>> qpidd.  I don't know hoe effective that will be, just a suggestion.
>> Thanks.  I may test with that, but for production I can't be sure that
> some department that I don't know about is using a V1 only tool.

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

View raw message