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? 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 > >
