qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Freeman <ke1g...@gmail.com>
Subject Re: Questions from a novice
Date Tue, 02 Apr 2013 20:12:11 GMT

On Tue, Apr 2, 2013 at 1:48 PM, Fraser Adams

> > I found this (https://cwiki.apache.org/qpid/qmfv2-project-page.html).  I
> > probably didn't go here the first time around because the link to it on
> > https://cwiki.apache.org/qpid/qpid-management-framework.html says that
> it
> > is "for information about the future of QMF", so I figured that it didn't
> > apply yet.
> That's the stuff I was referring to.

I have been reading this (except for the "design" link, which I apparently
have to be logged in in order to see).  I was tickled by the claim that one
can manage a federation through a single connection in QMF2, which seems
reasonable.  I had gotten the impression earlier in this thread that maybe
this could happen, but it would take work to set up.  So maybe this
requires links that the C++ agents aren't yet configuring automagically?
Or would it always require some by hand configuration, beyond that normally
needed for a federation?  (Not necessarily a Fraser question, but the kind
of thing I have been prodded into thinking about.)

> "didn't apply yet" is slightly ironic :-/, so the QMF2 protocol stuff
> definitely applies and is worth a read, the API is slightly a sore point. I
> believe that there is a python implementation in the "extras" directory
> that implements a reasonable subset of the API and my Java stuff went
> perhaps a little OTT as I implemented the whole lot - console, agent, query
> subscriptions, everything :-)
> Unfortunately it hasn't really taken off, the QMF2 versions of the python
> tools such as qpid-config actually use qpidlibtools which is an alternative
> API, I'm not sure that I totally agree with all the decisions taken with
> that, it's very broker agent specific and I'm not keen on ObjectIds being
> used in a non-opaque manner. that's all by the by though, the C++ QMF2
> stuff is even odder and has its own API that doesn't seem to be documented
> anywhere, I'm not sure where that originated.
> Most C++ QMF2 related things I've seen seem to use the protocol directly.
> I'm personally not keen on that. Although it's based on Map messages
> there's enough boiler plate to make an API useful and given that AMQP
> supports binary and UTF8 strings and multiple different integer and
> floating point widths there's a good argument for using an API to ensure
> that types are interoperable. A good chunk of my Java QmfData class was
> about defensive coding to cope with all sorts of ClassCastException hell, I
> got a real miscellany of binary and UTF8 strings from C++ agents, so I
> needed to be careful. That's definitely something that needs to be
> considered for the future management - we must do more to consider
> interoperability across languages.

I think that we're stuck with APIs having a fair amount of language
specific variations.  As a Python guy, probably all my integer value
normalization is handled already in the lower level qpid libraries that the
consoles uses, since in python an int is an int (at least after the
unification of long and int in the more recent python versions).  There are
probably things that are easy for Java but tough for python as well, but
you mentioned the integer widths.

> The bottom line is that QMF2 is somewhat fragmented, not to mention that
> it has been C++ broker specific (though I'm working to remedy that bit).
> It's something of a shame because despite its failings I've found QMF2 to
> be pretty useful and works pretty well, but the reality is that for AMQP
> 1.0 management something will need to be put in place that has wide vendor
> buy in and that most likely won't be QMF2 as it currently stands, though
> I'm certainly keen to make sure that any transition is as painless as
> possible. At the moment QMF is the only way to manage the C++ broker and
> there are a fair number of tools out there using it, so I think that any
> migration is going to have to be a bit evolutionary. It's a shame that the
> API hasn't really taken off as that might have helped isolate clients from
> changes to the underlying management protocol. As it is the QMF2 protocol
> is exposed by several fragmented, APIs which is clearly the exact opposite
> of what might be considered useful abstraction :-(

Am I correct that the work itme queue idea is a feature of the API, and
thus the Console super-class implementation, rather than forced by the
protocol?  I'm guessing that items arrive at the console from the broker
asynchronously, when they're ready, and the queue being drained with a zero
timeout is a within the console queue of the already arrived.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message