On 04/01/12 19:51, Rob Godfrey wrote:
On 4 January 2012 18:55, Ted Ross<[email protected]> wrote:
Users and Devs,
I'd like to make a proposal and start a discussion about the future of QMF
and Qpid broker management.
QMF (Qpid Management Framework) started out as a way to remotely manage
the Qpid C++ broker using AMQP messaging. There was an agent embedded in
the broker and a console API written in Python. It was then expanded for
more general purpose use when an agent library and API were developed so
developers could provide QMF manageability to their software components.
There has been quite a bit of evolution including new APIs and even a new
protocol based on map/list-encoded messages. One of the important changes
that occurred with the new protocol (called qmf2) was that QMF became
purely layered over AMQP messaging. The original protocol required the
participation of the broker to assign addresses, to track agents, and to
cache schema information (didn't scale well, didn't work in multi-broker
environments, had multiple protocol issues, wreaked havoc with clustering).
The QMF code is embedded in the "qpid" namespace because older versions
were tightly coupled to the broker code. Now that the coupling has been
reduced (consisting of the public messaging API), it is possible to move
QMF out of the "qpid" namespace and allow it to be a separate component,
with its own build and release artifacts.
I would like to propose that we:
1. move the C++ implementation of qmf2 out of the qpid tree and into
the "extras" subdirectory (where the Python implementation is),
2. move the swig bindings (Python, Ruby, etc.) into extras as well, and
3. deprecate the old qmf components.
The old components are in:
* cpp/{include,src}/console
* cpp/{include,src}/agent
* cpp/{include,src}/qmf/engine
* cpp/bindings/qmf
+1 I think this will be beneficial both for QMF and Qpid Core development.
Should we be thinking of spinning QMF off as a separate project in its own
right? I'm guessing that if the coupling is loose enough there is no need
to tie release schedules of QMF to the release cycles of the rest of the
project?
+1 from me. From the perspective of the Matahari project, this would
make QMF more visible and potentially make it easier for us to
contribute changes.
This proposal seems like an excellent first step down that path, as well
as a beneficial thing to do in its own right.
cheers,
Zane.
The last part of the proposal is to remove the dependency that the qpid
tools (qpid-config, qpid-stat, qpid-route, etc.) have on the Python QMF
library. If you haven't noticed, these tools run fairly slowly, especially
when grouped in large numbers in a script file. This is because QMF
(version 1) has a significant amount of handshake that occurs on connection
setup. Since the tools don't need agent-discovery or schema-introspection,
they can operate much more simply by sending and receiving properly
formatted messages to and from the broker agent. I prototyped this with
qpid-stat and found it to be visually instantaneous in its response time.
It also reduced the number of queues and bindings related to the
management session to one.
Can you confirm that you are going to be testing this with the Java Broker
as well as the C++?
Happy to help if there are any issues that crop up on the Java side of this.
Fraser Adams has contributed a Java implementation of the new QMF
protocol. It makes sense to me that this should be included with the C++
and wrapped components that I propose moving into "extras".
Agreed.
Cheers,
Rob
Thoughts?
Regards,
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
