On 27/02/14 18:38, Rob Godfrey wrote:
On 27 February 2014 18:57, Fraser Adams <[email protected]>wrote:
[snip]
So to get back to your point "Haven't you to some extent already done that
with your QMF adapter work" well yes, but it's not actually a simple yes/no
answer. The core properties/attributes all map fairly easily and I could
probably have got away without actually mapping those because I
introspected the names (I'll say why I did in a bit) but I *certainly*
needed to do something about the navigation because QMF and the Java Broker
Management Model take very different approaches. That's why I'm a little
troubled that AMQP 1.0 Management is agnostic about navigation/association
that's one of the hard bits and if everyone does their own thing then it'll
make it very hard indeed to create tooling that's not very bespoke.
I think this is a valid point... It's probably a worthwhile exercise to
think about the "standard" AMQP 1.0 entities and how they will be modelled
and their relationships. For AMQP 1.0 that probably starts of consisting
of "Nodes", "Links" and "Connections" (and possibly "Sessions"). In the
general AMQP model exchanges and bindings don't exist - though we could
maybe model them as node and bindings as "internal links" between nodes.
Funnily enough my "mental model" of AMQP 0.10 in an AMQP 1.0 context has
tended to be as above with bindings as "internal links".
Though it's probably not as clear-cut as that. For sure if a producer is
sending to an exchange (as an addressable node) and a consumer is
receiving from a queue (as an addressable node) and we've established
some bindings administratively then creating said bindings is pretty
close to establishing an internal link, However if one has a consumer
receiving from an exchange as an addressable node it gets more
interesting in that case although we have a queue created (in physical
terms) that queue is really an artefact of the subscription and is (I
think) actually a source terminus associated to the exchange node and
one or more links.
That's all quite "exciting" because the same physical things on the
broker are semantically a little different depending on how things were
established, which messes with my head a bit :-D don't know whether it's
possible (or whether you'd want to) distinguish between the two
different scenarios in a Management Model??
As it happens I actually mapped the properties because I was keen to see
if I could get it to work with the CLI tools such as qpid-config (as I say
it'd probably have looked decent with the UI with only the navigation
mapped). I mention that because I think migration from existing tooling is
going to be one of the more "interesting" aspects of moving to AMQP 1.0
Management. So as you know I did a Java Broker plug-in that does the
mapping 'cause that was a fairly obvious place, but if both C++ and Java
Brokers talk AMQP 1.0 Management there's no obvious place to do mappings -
I guess that the best hope in that case would be something like the client
side of qpidtoolibs and similar for Java and C++, but I haven't though too
hard about it yet (it's likely to need to happen in multiple places though
rather than in the one place it currently happens).
I think properties and associated behaviours is something we should
definitely be standardising between implementations under the Qpid
umbrella, and looking to standardize amongst other AMQP implementations.
That's not to say that all implementations will offer the same set, just
that we should (and I feel I've said this a million times already) use the
same properties and the same values for the same behaviours.
+ 1,000,000
I'm *definitely* all for this.
So the $64,000 question is how do we go about achieving that aim.
Clearly QMF and the Java Broker Management Models have diverged a bit so
it's going to require a degree of maturity across the C++ and Java
communities to agree on what the names and types should be. It sounds
simple, bet it isn't :-) but just because it's likely to be hard
shouldn't stop us trying, it's definitely the way to go.
Personally I think the biggest gap in the AMQP 1.0 management stuff right
now is any common way of describing "events" and a way to subscribe to
them, whether that be getting period statistic updates, or notification of
objects being created / deleted / etc. I feel that this is a common use
case and again by standardising we would enable a broad class of use-cases
to be enabled in a standard way without being overly prescriptive about
exactly what statistics might be supplied (number of mallocs anyone :-) ).
I agree with this completely.
I think I've said this to you before, but I do get a little frustrated
by the AMQP 1.0 Management stuff. For all its failings I do happen to
think that QMF2 is actually pretty good and had successfully addressed
most of the things we've been discussing and in addition had some pretty
sophisticated capabilities for generating events and in addition it had
the ability to allow clients to specify "query subscriptions" that told
an Agent to "push" specified data. As it happens the C++ broker didn't
implement query subscriptions rather it retained the QMF1 data push but
I implemented all this stuff in the Java QMF stuff and my Agent code can
do query subscriptions and I implemented client side code so I could
"fake" query subscriptions client side from broker data pushes.
Anyway what I'm trying to say is that I feel slightly worried that
there's wheel reinvention going on. I really *do* get the fact that a
key aim is to be interoperable and it would have been hard to get a wide
range of vendors to buy into something called "Qpid Management
Framework" but in many ways I feel that an approach of starting with
QMF2 and paring it back a bit (I do think some of the QMF
request/response properties are annoyingly convoluted!!) would have been
a better approach.
Perhaps I'm just a bit naive about multi-vendor politics.
I do kind of agree with your comment "number of mallocs anyone ", but
the right thing might be to have a generalisation of a "Broker"
Manageable Entity that covers common broker like useful stuff and
specialisations for different platforms and in this case perhaps number
of mallocs might be perfectly reasonable (- ust 'cause you can attach a
JConsole to the Java Broker doesn't mean it's possible in C++, you're
just spoilt :-)
You'll recall a few threads on "Plans for QMF v1 and v2" last Easter that
were spawned on the back of plans to disable v1 push messages from qpidd by
default and the resulting realisation that the Python asynchronous API only
really worked for v1 at the time. I think that's probably the tip of the
iceberg compared to migrating to AMQP 1.0 Management. Perhaps the right
answer is not to migrate but rather make a clean break with new tools? I
don't know, do you guys have a preference?
On the Java side we'll continue supporting the existing management
mechanisms (which are implemented as plugins) but out internal tooling will
be focussed on AMQP manegement alongside the REST/API where appropriate.
We will be trying very hard to keep the two of these using the same model
so transitioning from one to the other should be seemless.
That's good, FWIW I think that the plugin based approach on the Java
Broker has been a very good call - except when the API changes ;-D I'm
certainly more worried about the complexity of the transition for the
QMF/C++/Python community. That said I think that you're still going to
have some issues - for example if say some properties change as a result
of the sort of standardisation we've been discussing would you simply
change them and expect say users of the JMX plugin to handle this
themselves, or would you do a mapping to isolate users of your "legacy"
interfaces?
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
