Many thanks for the clarification Robbie, I guess that the full picture
continues to offer us some warnings from history.
At one level the issue "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 " essentially still exists (albeit without a direct schema
coupling).
One of the things that worries me a little is that in many ways (given
my far from perfect understanding) QMF2 and AMQP 1.0 Management Spec.
share many similarities (no mandatory schema - it's all introspectable
being encoded as AMQP Maps) that's great and offers the ability to align
well at the protocol level, but the differences in the management models
between the two Qpid brokers and of course with other AMQP brokers and
services will continue to make developing cohesive tooling a challenge.
That's life I guess, I guess that you can't expect
Microsoft/IBM/RabbitQ/ActiveMQ/Qpid/etc to offer identical feature sets
but AMQP 1.0 management isn't going to fix that. As you say the Java
Broker has evolved at lot and you've got a lot of quite low level
features in the Management Model that are exposed in the embedded Web
GUI. What I'm not clear on is how far your thinking has progressed along
the options for eventually "externalising" this via AMQP 1.0 Management
and making it available on "external" tooling. That's *largely* what
I've done in the QMF2 space - albeit incomplete/imperfect/whatever, as I
say I think that there are a lot of similarities between QMF2 and AMQP
1.0 Management and a big part of my motivation was proving that it was
possible and exposing the sorts of wrinkles that we might expect (in
particular I guess that I've only exposed the lowest common denominator).
Perhaps the generality of AMQP 1.0 and the needs of Vendors to make
their product sets readily differentiable might mean that we'll never
hit the Nirvana of one Vendor's tooling managing another Vendor's broker
- I mentioned to Rob back at Easter that I worried that the lack of
schemas might make this a lot harder too. I wouldn't want to be coupled
to a schema like QMF1 is, but having a schema available might make it
easier to create generic tooling that is *semantically* meaningful.
Without it the most we can expect from a generic tool is to be a bit
like a JMX Console, which is OK but a bit ugly.
Thanks again for the background, it's really interesting and I think
knowledge of the history is incredibly useful to help us (try to) avoid
the same wrinkles going forward.
Frase
On 24/01/14 01:11, Robbie Gemmell wrote:
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
