You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Ted Ross <tr...@redhat.com> on 2012/01/04 18:55:59 UTC
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
Re: QMF and Broker Management
Posted by Gordon Sim <gs...@redhat.com>.
On 01/04/2012 05:55 PM, Ted Ross wrote:
> I'd like to make a proposal and start a discussion about the future of
> QMF and Qpid broker management.
[...]
> 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),
Under extras/qmf there is the 'old' console API and something called
qmf2-prototype. Just for clarity, what is the status of that second module?
> 2. move the swig bindings (Python, Ruby, etc.) into extras as well, and
> 3. deprecate the old qmf components.
When would you envisage being able to drop them entirely?
> The old components are in:
>
> * cpp/{include,src}/console
> * cpp/{include,src}/agent
Again just for clarity, the old code is in
cpp/{include,src}/*qpid*/console and cpp/{include,src}/*qpid*/agent,
right? Is the qmfv2 implementation that is to be moved the code in
cpp/{include,src}/qmf/ apart from the engine subdirectory?
> * cpp/{include,src}/qmf/engine
> * cpp/bindings/qmf
What about the qmf-gen utility? Would that move also? Or is that now
something specific to the C++ broker?
> 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.
So you're proposing these would be self-contained utilities, with no
dependencies on any QMF libraries? (Or are you proposing they be
migrated to 'new' QMF libraries?)
The tools - and indeed the broker schema - have evolved in a rather
ad-hoc manner. While I find them useful, there are some limitations and
some areas where this ad-hoc evolution shows through. I'd like to see a
more holistic and comprehensive and forward looking review at some point.
[...]
> 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".
We have previously discussed introducing a 'sandbox' or 'nursery' area
to which new components would initially be added until we have proven -
as a community - that we can support them. I think this would be a good
candidate for such a scheme (to avoid repeating the experience with the
Java implementation of QMFv1 that was contributed).
In general, I would welcome moving the agent and console APIs and their
implementations out of the qpid tree.
I would also like to see broker management get more attention in its own
right. I feel that focus has sometimes been sacrificed to the more
general goals of QMF.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Zane Bitter <zb...@redhat.com>.
On 04/01/12 19:51, Rob Godfrey wrote:
> On 4 January 2012 18:55, Ted Ross<tr...@redhat.com> 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:users-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Zane Bitter <zb...@redhat.com>.
On 04/01/12 19:51, Rob Godfrey wrote:
> On 4 January 2012 18:55, Ted Ross<tr...@redhat.com> 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:dev-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Russell Bryant <rb...@redhat.com>.
On 01/04/2012 01:51 PM, Rob Godfrey wrote:
> +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?
I think splitting out QMF to be an independent project makes a lot of
sense. I think that it could help with driving QMF awareness and
adoption for use cases beyond broker management.
--
Russell Bryant
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
On 05/01/12 16:28, Robbie Gemmell wrote:
> I also think that if any moves are being done, I would go further than
> just bumping them into the extras directory. That still isnt all that
> visible or seperate from Qpid in itself, I think the core QMF
> components would collectively warrant at least sub project status with
> their own release timelines and website etc.
>
> Robbie
I sent much of this reply on the Java QMF2 API thread but I thought I'd
add it here too.
I think I'm pretty much a "+1" too. I'd tend to agree with Ted, yourself
and the others that it's a good idea to separate QMF from the Qpid
namespace and consider QMF to be a separate and layered capability that
adds value to Qpid. That's exactly the case with the Java API
implementation, which is really to all intents and purposes just a JMS
application.
My one reservation is that if QMF got separated there may be a danger
that it could become a bit of a second class citizen, I'd be very keen
to avoid that happening.
As it happens one of the reasons I started down the path of the Java
QMF2 API implementation was because the original Java QMF stuff seemed
very broken (and it was mentioned that it was not supported/maintained
and up for removal from the code base). Given my experience with the
QMF2 stuff I suspect where the original Java QMF stuff is most likely to
be broken is in the String handling. I've mentioned in several threads
lots of nasty interoperability issues due to C++ binary strings (as
opposed to utf8 encoded strings), which get mapped into byte[]. I've put
in a lot of defensive coding to cater for this.
If I'm honest I think that my preference is to have QMF initially as a
sub-project under the qpid umbrella so that there's some initial
monitoring from the core qpid community to ensure that there's
sufficient "traction". IMHO QMF is too important to qpid to be allowed
to stagnate - indeed I'd like to see a whole lot of additional
development done.
Part of my motivation for the Java QMF stuff was to try and kick start
some of this. One of the things that you often see with other messaging
providers are fancy consoles and the like, but with qpid (particularly
the C++ broker) things are a bit more limited to command line utilities,
which may put people off.
I'd very much like to see the QMF stuff tidied up in the C+ broker code
base so I like Ted's suggestion "move the C++ implementation of qmf2 out
of the qpid tree". When I was trying to figure out what was going on I
ended up down a lot of blind alleys because of the somewhat confusing
structure of the code base as-is.
I guess the elephant in the room is what to do about QMF1. Is the
intention to deprecate this? Clearly the standard tools could be
rewritten using QMF2API (or indeed just use the protocol), but what
about people who've written bespoke consoles/agents using the old
API/Protocol?
IMHO it rather waters down Ted's proposal to move out QMF2 but keep the
old QMF1 stuff in the core code base - indeed it could make things very
confusing.
One possibility that I've been musing over is that if we layer QMF we
could provide a "wrapper" at the edges to "transcode" to the QMF1 protocol.
Another option is to provide QMF1 and QMF2 APIs but under the hood they
both talk the QMF2 protocol. I guess that'll break down if anyone has
written consoles/agents that speak the old QMF1 protocol directly rather
than using the API, but I'd suspect that is fairly unlikely given how
much of a faff that would be.
Frase.
>
> On 4 January 2012 18:51, Rob Godfrey<ro...@gmail.com> wrote:
>> On 4 January 2012 18:55, Ted Ross<tr...@redhat.com> 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
>>>
>>>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Robbie Gemmell <ro...@gmail.com>.
I also think that if any moves are being done, I would go further than
just bumping them into the extras directory. That still isnt all that
visible or seperate from Qpid in itself, I think the core QMF
components would collectively warrant at least sub project status with
their own release timelines and website etc.
Robbie
On 4 January 2012 18:51, Rob Godfrey <ro...@gmail.com> wrote:
> On 4 January 2012 18:55, Ted Ross <tr...@redhat.com> 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
>>
>>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Russell Bryant <rb...@redhat.com>.
On 01/04/2012 01:51 PM, Rob Godfrey wrote:
> +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?
I think splitting out QMF to be an independent project makes a lot of
sense. I think that it could help with driving QMF awareness and
adoption for use cases beyond broker management.
--
Russell Bryant
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Rajith Attapattu <ra...@gmail.com>.
I agree with Rob and others about QMF being it's own project with
independent release cycles/website etc.
We could probably start as a sub project of Qpid and depending on how it
goes make a proposal to move it to a top level project.
Rajith
On Wed, Jan 4, 2012 at 1:51 PM, Rob Godfrey <ro...@gmail.com> wrote:
> On 4 January 2012 18:55, Ted Ross <tr...@redhat.com> 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
> >
> >
>
Re: QMF and Broker Management
Posted by Robbie Gemmell <ro...@gmail.com>.
I also think that if any moves are being done, I would go further than
just bumping them into the extras directory. That still isnt all that
visible or seperate from Qpid in itself, I think the core QMF
components would collectively warrant at least sub project status with
their own release timelines and website etc.
Robbie
On 4 January 2012 18:51, Rob Godfrey <ro...@gmail.com> wrote:
> On 4 January 2012 18:55, Ted Ross <tr...@redhat.com> 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
>>
>>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Rob Godfrey <ro...@gmail.com>.
On 4 January 2012 18:55, Ted Ross <tr...@redhat.com> 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
>
>
Re: QMF and Broker Management
Posted by Rob Godfrey <ro...@gmail.com>.
On 4 January 2012 18:55, Ted Ross <tr...@redhat.com> 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
>
>
RE: QMF and Broker Management
Posted by Steve Huston <sh...@riverace.com>.
This looks great - I support the move!
-Steve
> -----Original Message-----
> From: Ted Ross [mailto:tross@redhat.com]
> Sent: Wednesday, January 04, 2012 12:56 PM
> To: users@qpid.apache.org; 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:users-subscribe@qpid.apache.org
RE: QMF and Broker Management
Posted by Steve Huston <sh...@riverace.com>.
This looks great - I support the move!
-Steve
> -----Original Message-----
> From: Ted Ross [mailto:tross@redhat.com]
> Sent: Wednesday, January 04, 2012 12:56 PM
> To: users@qpid.apache.org; 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:dev-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Gordon Sim <gs...@redhat.com>.
On 01/04/2012 05:55 PM, Ted Ross wrote:
> I'd like to make a proposal and start a discussion about the future of
> QMF and Qpid broker management.
[...]
> 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),
Under extras/qmf there is the 'old' console API and something called
qmf2-prototype. Just for clarity, what is the status of that second module?
> 2. move the swig bindings (Python, Ruby, etc.) into extras as well, and
> 3. deprecate the old qmf components.
When would you envisage being able to drop them entirely?
> The old components are in:
>
> * cpp/{include,src}/console
> * cpp/{include,src}/agent
Again just for clarity, the old code is in
cpp/{include,src}/*qpid*/console and cpp/{include,src}/*qpid*/agent,
right? Is the qmfv2 implementation that is to be moved the code in
cpp/{include,src}/qmf/ apart from the engine subdirectory?
> * cpp/{include,src}/qmf/engine
> * cpp/bindings/qmf
What about the qmf-gen utility? Would that move also? Or is that now
something specific to the C++ broker?
> 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.
So you're proposing these would be self-contained utilities, with no
dependencies on any QMF libraries? (Or are you proposing they be
migrated to 'new' QMF libraries?)
The tools - and indeed the broker schema - have evolved in a rather
ad-hoc manner. While I find them useful, there are some limitations and
some areas where this ad-hoc evolution shows through. I'd like to see a
more holistic and comprehensive and forward looking review at some point.
[...]
> 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".
We have previously discussed introducing a 'sandbox' or 'nursery' area
to which new components would initially be added until we have proven -
as a community - that we can support them. I think this would be a good
candidate for such a scheme (to avoid repeating the experience with the
Java implementation of QMFv1 that was contributed).
In general, I would welcome moving the agent and console APIs and their
implementations out of the qpid tree.
I would also like to see broker management get more attention in its own
right. I feel that focus has sometimes been sacrificed to the more
general goals of QMF.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Ken Giusti <kg...@redhat.com>.
+1 - totally agree with this proposal.
----- Original Message -----
> 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:users-subscribe@qpid.apache.org
Re: QMF and Broker Management
Posted by Ken Giusti <kg...@redhat.com>.
+1 - totally agree with this proposal.
----- Original Message -----
> 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:dev-subscribe@qpid.apache.org