This looks great - I support the move! -Steve
> -----Original Message----- > From: Ted Ross [mailto:[email protected]] > Sent: Wednesday, January 04, 2012 12:56 PM > To: [email protected]; Qpid Dev > Subject: QMF and Broker Management > > 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 > > 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. > > 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". > > Thoughts? > > Regards, > > -Ted --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
